Method and system for utilizing authorization factor pools

ABSTRACT

One embodiment of the present disclosure provides a system and associated processes for sharing cardholder data (CHD) between a merchant that utilizes tokenization and a second merchant that may or may not utilize tokenization. In one embodiment, the merchant, or an employee of the merchant, can use the system and associated processes to reacquire CHD from a tokenization provider system. In one embodiment, the merchant identifies to the tokenization provider system a desire to share CHD, which is associated with a token, with a second merchant. The merchant and/or the tokenization provider system can then invite the second merchant to register with the tokenization provider system. Once registered with the tokenization provider system, the second merchant can access any CHD that the merchant associated with the second merchant.

RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.13/941,282, filed on Jul. 12, 2013 and titled “METHOD AND SYSTEM FORUTILIZING AUTHORIZATION FACTOR POOLS,” which is a divisional applicationof U.S. application Ser. No. 13/797,246, filed on Mar. 12, 2013 andtitled “METHOD AND SYSTEM FOR UTILIZING AUTHORIZATION FACTOR POOLS,”which claims priority to and is a continuation-in-part of U.S.application Ser. No. 13/303,983, filed on Nov. 23, 2011 and titled“METHOD AND SYSTEM FOR ENABLING MERCHANTS TO SHARE TOKENS,” which is anonprovisional of U.S. Provisional Application No. 61/476,194, filed onApr. 15, 2011 and titled “METHOD AND SYSTEM FOR SHARING TOKENS,” each ofwhich is hereby incorporated by reference in its entirety herein.Further, U.S. application Ser. No. 13/797,246 claims priority to U.S.Provisional Application No. 61/621,222, filed on Apr. 6, 2012 and titled“METHOD AND SYSTEM FOR ENABLING MERCHANTS TO SHARE TOKENS,” and to U.S.Provisional Application No. 61/714,959, filed on Oct. 17, 2012 andtitled “METHOD AND SYSTEM FOR ENABLING MERCHANTS TO SHARE TOKENS,” eachof which is hereby incorporated by reference in its entirety herein. Inaddition, U.S. application Ser. No. 13/797,246 was filed on Mar. 12,2013, the same day as U.S. application Ser. No. 13/796,969 titled“MERCHANT-BASED TOKEN SHARING,” which is hereby incorporated byreference in its entirety herein.

BACKGROUND

Tokenization is a process used in credit, debit, and gift cardprocessing systems to avoid storing cardholder data (CHD) such as creditand debit card numbers, pin numbers, expiration dates, card securitycodes, and the like at a merchant's location. For example, when amerchant initially accepts a credit card at a point-of-sale (POS)system, the CHD is encrypted and sent to a remote gateway system. Thegateway system requests authorization from a credit card processor,which obtains authorization from a bank that issued the card. Thegateway system receives the authorization from the credit card processorand provides a token to the merchant for storage along with theauthorization.

The token can be a globally unique, randomized, alphanumeric replacementfor the CHD. The merchant's POS system stores the token instead ofstoring the CHD. If the merchant needs to reauthorize a customer (forexample, to add a tip at a restaurant), the merchant sends the token tothe gateway system, which then sends the actual CHD to the processor.With tokenization, thieves cannot steal CHD from merchants because thetokens are stored in place of the actual CHD.

SUMMARY

Embodiments of the present disclosure relate to a system for sharingcardholder data (CHD). In some embodiments, the system includes atokenization system. The tokenization system may be configured toreceive CHD of a cardholder, or customer, from a first merchant. Thetokenization system can associate a token with the CHD in physicalcomputer storage to thereby enable the token to be used to represent theCHD or, in some cases, in place of the CHD. Further, the tokenizationsystem may be configured to electronically transmit the token to thefirst merchant so as to enable the first merchant to perform a firsttransaction for the cardholder without having to store the CHD. In someimplementations, the system may include a token-access granting systemthat includes computer hardware. The token-access granting system may beconfigured to receive an indication from the first merchant that one ormore of the token and the CHD are to be shared with a second merchant.In response to receiving the indication, the token-access grantingsystem may be configured to authorize the second merchant to access oneor more of the token and the CHD, thereby enabling the second merchantto perform a second transaction for the cardholder.

Additional embodiments of the present disclosure relate to a method forsharing a token associated with cardholder data (CHD) in a tokenizationprovider system to enable the sharing of cardholder data between users.In certain embodiments, the method may be performed by a token accesssystem implemented in a computing system that includes one or moreprocessors. The method may include generating a first set of words andassociating the first set of words with a token. The token may beassociated with CHD in a tokenization provider system. The method mayfurther include associating, in computer memory of the token accesssystem, the first set of words with a user. In addition, the method mayinclude providing access to the first set of words to the user. Themethod may also include receiving user authentication informationassociated with the user and receiving a second set of words from theuser. In some implementations, the method includes determining whetherthe user is authorized to use the token by at least authenticating theuser based, at least in part, on the user authentication information,and determining whether the second set of words matches the first set ofwords. In response to determining that the user is authorized to use thetoken, the method may include providing the user with electronic accessto the token.

Some embodiments of the present disclosure relate to a system forsharing cardholder data (CHD). This system may include a tokenacquisition system configured to provide CHD of a cardholder to atokenization provider system. Further, the token acquisition system maybe configured to receive electronically a token associated with the CHDso as to enable a first merchant associated with the token acquisitionsystem to perform a first transaction for the cardholder without havingto store the CHD. In some implementations, the system includes a tokensharing system configured to provide to the tokenization provider systeman indication that one or more of the token and the CHD are to be sharedwith a second merchant, thereby enabling the second merchant to performa second transaction for the cardholder.

BRIEF DESCRIPTION OF THE DRAWINGS

Throughout the drawings, reference numbers are re-used to indicatecorrespondence between referenced elements. The drawings are provided toillustrate embodiments of the inventive subject matter described hereinand not to limit the scope thereof.

FIG. 1 illustrates an example embodiment of a token-sharing environment.

FIG. 2 illustrates a flow diagram for an example embodiment of a tokenprovisioning process.

FIG. 3 illustrates a flow diagram for an example embodiment of a processfor accessing cardholder data.

FIG. 4 illustrates a flow diagram for a second example embodiment of atoken provisioning process.

FIG. 5 illustrates a flow diagram for a second example embodiment of aprocess for accessing cardholder data.

FIG. 6 illustrates a flow diagram for an example flow of informationusing a tokenization provider system.

FIG. 7 illustrates an example embodiment of a user login interface.

FIG. 8 illustrates an example embodiment of a user registrationinterface.

FIG. 9 illustrates an example embodiment of a merchant selectioninterface.

FIG. 10 illustrates an example embodiment of a populated merchantselection interface.

FIG. 11 illustrates an example embodiment of a CHD access interface.

FIG. 12 illustrates an example of a CHD provisioning interface.

FIG. 13 illustrates an example embodiment of a token-sharingenvironment.

FIG. 14 illustrates a flow diagram for an example embodiment of aprocess for accessing a token.

FIG. 15 illustrates a flow diagram for a third example embodiment of aprocess for accessing cardholder data.

FIG. 16 illustrates an example embodiment of a token access system.

FIG. 17 illustrates a flow diagram for an example embodiment of aninteractive voice response (IVR) based token sharing process.

FIG. 18 illustrates a flow diagram for an example embodiment of a tokengeneration process.

FIG. 19 illustrates an example embodiment of a token-sharingenvironment.

FIG. 20 illustrates a flow diagram for a third example embodiment of atoken provisioning process.

FIG. 21 illustrates a flow diagram for a fourth example embodiment of aprocess for accessing cardholder data.

FIG. 22 illustrates a flow diagram for an example embodiment of atoken-provisioning process using a machine-readable code.

FIG. 23 illustrates a flow diagram for an example embodiment of aprocess for accessing CHD using a machine-readable code.

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS Introduction

The security advantages of tokenization sometimes come at the expense offlexibility. Because a merchant that uses tokenization stores a tokeninstead of cardholder data (CHD), the merchant cannot share the CHD witha second merchant. This inability to share CHD can affect the merchant'sability to fully service his or her customers. For example, many qualityhotels will make restaurant reservations, order flowers, reserve theatretickets, and provide a number of additional services for guests thathelp differentiate these quality hotels from lesser quality hotels.However, without access to CHD, it becomes more difficult if notimpossible to provide guests with these aforementioned services.

Further, the lack of access to CHD by merchants that use third-partyservices, which take advantage of tokenization, can affect the abilityof some merchants to charge for cancelled reservations. For example, agolf course may work with a vacation reservation company to selltee-times to vacationers. If a vacationer fails to show up withoutproperly cancelling his or her reservation, the golf course may wish tocharge the vacationer a cancellation fee. However, if the vacationreservation company utilizes a tokenization service, the vacationreservation company will be unable to provide the golf course with theCHD.

Moreover, there are instances where a merchant may desire to reacquireCHD. For example, the merchant may want to process a transaction thatincludes interacting with a payment or credit card processor that is notsupported by the tokenization gateway, which handles transactions onbehalf of merchants that opt to use tokenization.

One embodiment of the present disclosure provides a system andassociated processes for sharing CHD between a merchant that usestokenization and a second merchant that may or may not use tokenization.In one embodiment, the merchant, or an employee of the merchant, can usethe system and associated processes to reacquire CHD from a tokenizationprovider system. In one embodiment, the merchant identifies to thetokenization provider system a desire to share CHD, which is associatedwith a token, with a second merchant. If the second merchant is notregistered with the tokenization provider system, the merchant and/orthe tokenization provider system can invite the second merchant toregister with the tokenization provider system. Once registered with thetokenization provider system, the second merchant can access any CHDthat the initial merchant associates with the second merchant.

In one embodiment, the second merchant identifies the token associatedwith the CHD to the tokenization provider system. If the merchant hasgiven the second merchant access to the token, then the tokenizationprovider system can provide the second merchant with the CHD. In oneembodiment, providing the CHD to the second merchant comprises thetokenization provider system performing a transaction using the CHD forthe second merchant. Advantageously, in some embodiments, thetokenization provider performing the transaction for the second merchantmaintains the security advantages gained from tokenization because thesecond merchant can use the CHD without the second merchant viewing theCHD and without a copy of the CHD being sent to the second merchant'slocation. In one embodiment, once the second merchant acquires the CHD,the second merchant can use the tokenization provider system, or thesecond merchant's tokenization provider system, to obtain a new tokenassociated with the CHD and the second merchant. The second merchant canthen take advantage of tokenization and avoid storing the CHD at thesecond merchant's location.

In one embodiment, providing the second merchant with access to thetoken and/or the CHD associated with the token comprises providing thesecond merchant with an authorization factor. This authorization factoris associated with one or more of the token, the CHD, and the secondmerchant. In one embodiment, to access the token and/or CHD, thetokenization provider system can request that the second merchantpresent the authorization factor as part of the user authenticationprocess. Advantageously, in some embodiments, use of the authorizationfactor prevents automated systems from accessing the token and/or CHD.Further, in some embodiments, use of the authorization factor increasesthe security of the CHD because, in certain embodiments, the CHD isprotected by two levels of obscurity. A user attempting to access theCHD may be required to authenticate with the tokenization providersystem and provide the authorization factor. Further, the authorizationfactor can be associated with the CHD and the user thereby preventing auser who is authorized to access the tokenization provider system, butnot the CHD from accessing the CHD.

Many variations of these example systems and associated processes aredescribed below in more detail with reference to the drawings. Further,in some cases, one or more of the various embodiments and systems can becombined into fewer embodiments or systems or split into multipleembodiments or systems.

Example Token-Sharing Environment

FIG. 1 illustrates an example embodiment of a token-sharing environment100. The token-sharing environment 100 can comprise a tokenizationprovider system 102, a merchant environment 104, and a third-partymerchant environment 106.

The tokenization provider system 102 is associated with a tokenizationprovider (not shown) and can generally include any system capable ofcreating a token associated with CHD, storing the token and the CHD, andproviding the token to a user (e.g. a merchant 142) of the tokenizationprovider system 102. Further, the tokenization provider system 102 cangenerally include any system capable of performing a payment cardtransaction on behalf of the merchant 142 without the merchant 142having or maintaining a copy of the CHD. This CHD can include anyinformation associated with a customer of the merchant environment 104and the customer's payment card that is necessary to process a paymenttransaction, but which the merchant 142 does not wish to store at themerchant environment 104 due to, for example, security-related expensesor concerns. Further, the payment card can be any type of card that canfacilitate completing the payment transaction. For example, the paymentcard can be a credit card, debit card, or gift card. One example of sucha tokenization provider system is the Dollars On The Net® solution fromShift4® Corporation of Las Vegas, Nev.

The merchant environment 104 can generally include any product orservice provider that accepts credit cards, or other types of paymentcards, for payment and utilizes the tokenization provider system 102 forpayment processing. For example, the merchant environment 104 can be ahotel, an electronics store, a restaurant, an online ecommerce website,or a healthcare provider, to name a few. Further, the merchantenvironment 104 may be associated with an organization, or merchantorganization, that is affiliated with or owns one or more merchantenvironments. For example, assuming the merchant environment representsa hotel, the organization may be associated with a number of hotellocations and/or hotel chains.

Generally, the merchant organization is a different organization thanthe tokenization provider. However, in some embodiments, the merchantorganization may be the same organization as the tokenization providerthat is associated with the tokenization provider system 102. Forexample, the tokenization provider system 102 may represent, at least inpart, the corporate headquarters for the merchant organization or it mayrepresent a central processing facility for processing paymenttransactions for one or more locations of the merchant environment 104.Further, the merchant environment 104 may represent a store locationowned by the merchant organization, or the merchant environment 104 mayrepresent a franchisee.

In one embodiment, the merchant environment 104 includes a merchant 142and an administrator 148. The merchant 142 can represent any individual(e.g. an employee) affiliated with the merchant environment 104 who mayor may not have administrative access to an account associated with thetokenization provider system 102. The admin 148 can represent anyindividual affiliated with the merchant environment 104 who hasadministrative access to an account associated with the tokenizationprovider system 102. For example, the admin 148 can be a manager or anowner of the merchant environment 104.

The third-party merchant environment 106 can generally include anyproduct or service provider that accepts credit cards, or other types ofpayment cards, for payment and may or may not utilize the tokenizationprovider system 102 for payment processing. For example, the third-partymerchant environment 106 can be a flower shop, a hotel, a theatre,another ecommerce website, or a franchisee of the merchant environment104. In one embodiment, the third-party merchant environment 106 mayutilize a tokenization provider system that is not affiliated with thetokenization provider system 102. In one embodiment, the third-partymerchant environment 106 includes a third-party merchant 162. Thethird-party merchant 162 can represent any individual associated withthe third-party merchant environment 106.

In one embodiment, the merchant 142 can obtain CHD from a cardholder, orcustomer, (not shown) during a first or initial transaction. When themerchant 142 provides the CHD to the POS 144, the POS 144 can providethe CHD to a token access system 122, which is associated with thetokenization provider system 102. In turn, the token access system 122can provide the POS 144 with a token associated with the CHD. This tokencan be generated by the token access system 122 or a token generationsystem (not shown) that is associated with the tokenization providersystem 102. The POS 144 can then delete any CHD and can store the tokenat the token repository 152, which is part of the merchant repositorysystem 150. Further, the POS 144 can associate the token with acardholder, or customer, profile associated with the cardholder, orcustomer, and stored at the customer profile repository 154, which ispart of the merchant repository system 150. The token access system 122can store the CHD and the token, as well as the relationship between thetoken and the CHD, at the token/CHD relationship repository 132, whichis part of the tokenization provider repository system 130.

The POS 144 can generally represent any point-of-sale system that canprocess payment card transactions by communicating with the credit cardprocessors 172, or by communicating with the tokenization providersystem 102, which communicates with the credit card processors 172 forthe POS 144. The tokenization provider system 102 may communicate withthe credit card processors 172 using, for example, the gateway 126. Inone embodiment, the POS 144 communicates directly with the tokenizationprovider system 102 via a private secure connection. Alternatively, thePOS 144 can communicate with the tokenization provider system 102 viathe network 170. The network 170 can include any type of wired orwireless network. For example, the network 170 can be a LAN, WAN, or theInternet, to name a few. The credit card processors 172 and the creditcard processor 174 can generally include any payment card processingsystem or service.

The token access system 122 can generally include any system that cangenerate tokens associated with CHD and provide the tokens to a merchantenvironment 104. Further, the token access system 122 can include anysystem that can regulate access to the tokens, and CHD associated withthe tokens.

The merchant repository system 150 can generally include any repository,database, or information storage system that can store informationassociated with the merchant environment 104. In one embodiment, themerchant repository system 150 comprises the token repository 152 andthe customer profile repository 154. The token repository 152 cangenerally include any system capable of storing tokens associated withCHD. In one embodiment, the token repository 152 stores tokenidentifiers associated with tokens stored at the tokenization providersystem 102. In some cases, the token repository 152 stores hashed and/orencrypted versions of the token instead of, or in addition to, thetoken. The customer profile repository 154 can generally include anyinformation associated with customers of the merchant environment 104that the merchant environment 104 may store. For example, the customerprofile repository 154 may include the cardholder's or customer'sidentity, the customer's preferences (e.g. red flowers or a corner hotelroom), and the customer's purchase history, to name a few. In oneembodiment, one or more of the token repository 152 and the customerprofile repository 154 may store information linking an entry in thecustomer profile repository 154 with an entry in the token repository152 thereby associating a token with a customer. In one embodiment, thetoken repository 152 and the customer profile repository 154 can becombined or divided further.

The tokenization provider repository system 130 can generally includeany repository, database, or information storage system that can storeinformation associated with the tokenization provider system 102. In oneembodiment, the tokenization provider repository system 130 comprises atoken/CHD relationship repository 132, a token access repository 134,and a CHD access log repository 136. The token/CHD relationshiprepository 132 can generally include any system that can store CHD andtokens, as well as the relationship between the tokens and the CHD. Thetokens and CHD may each be stored in a hashed and/or encrypted form. Thetoken access repository 134 can generally include any system that canstore information associated with identifying who can access the tokensand CHD maintained by the tokenization provider system 102. Thisinformation can include user identification information, userauthentication information, and user/token relationship information, toname a few. The CHD access log repository 136 can generally include anysystem that can store information associated with token and CHD accessby users of the tokenization provider system 102. These users caninclude both users who use the tokenization provider system 102 fortokenization services (e.g. the merchant 142) and users who access thetokenization provider system 102 to access shared tokens or CHD (e.g.the third-party merchant 162). In one embodiment, the token/CHDrelationship repository 132, the token access repository 134, and theCHD access log repository 136 can be combined or divided further.

In one embodiment, the merchant 142 can provide the third-party merchant162 with access to the CHD. Providing the third-party merchant 162 withaccess to the CHD comprises the merchant 142 providing the third-partymerchant 162 with access to the token associated with the CHD. Toprovide the third-party merchant 162 with access to the CHD, themerchant 142 can send the token or token identifier and a merchantidentifier associated with the third-party merchant 162 to the tokenaccess system 122. Further, the token access system 122 provides thetoken or a token-identifier to the third-party merchant 162 enabling thethird-party merchant 162 to access the CHD associated with the token atthe tokenization provider system 102.

In one embodiment, the merchant 142 provides the token or thetoken-identifier to the third-party merchant 162 using, for example, thecomputing system 146 thereby enabling the third-party merchant 162 toaccess CHD associated with the token at the tokenization provider system102.

In one embodiment, access to the CHD is generally on a limited basis.For example, using the token, the third-party merchant 162 may only beable to access the CHD once, a small number of times, or for apredefined period (such as 15-minutes). However, access to the CHD isnot so limited in other embodiments.

In one embodiment, the merchant 142 can remove access to the CHD fromthe third-party merchant 162 by requesting that the token access system122 disassociate the token from the third-party merchant 162.

In some embodiments, the merchant 142 provides token access to one ormore users that have been pre-identified to the tokenization providersystem 102 by the admin 148 using, for example, the computing system146. Similarly, in some embodiments, the admin 148 can remove access tothe CHD from the one or more pre-identified users. In one embodiment,the pre-identified users can be third-parties (e.g. the third-partymerchant 162) and/or users associated with the merchant environment 104(e.g. the merchant 142).

In some embodiments, although the third-party merchant 162 may or maynot be a customer of the tokenization provider, to access the CHD, thethird-party merchant 162 registers with the token access system 122.Registration with the token access system 122 enables the token-accesssystem 122 to associate the token with the third-party merchant 162.Further, the registration enables the tokenization provider tooptionally verify the identity of the third-party merchant 162 and todetermine if the third-party merchant 162 is trustworthy based onpublicly available information or any other information source availableto the tokenization provider.

In one embodiment, the third-party merchant 162 accesses the tokenaccess system 122 via a computing system 164 or a POS 166. Thethird-party merchant 162 authenticates with the token access system 122and can then request the CHD associated with a token by providing a copyof the token or a token identifier associated with the token to a CHDaccess system 124. If the third-party merchant 162 has beenpre-authorized by the admin 148 to access the CHD, the CHD access system124 can provide the third-party merchant 162 with access to the CHD.Once the third-party merchant 162 has gained access to the CHD, thethird-party merchant 162 can process a transaction for the customer viathe POS 166 using the CHD. Alternatively, if the third-party merchant162 is a customer of the tokenization provider, the third-party merchant162 can use the gateway 126 to process the transaction. In oneembodiment, gaining access to the CHD enables the third-party merchant162 to view the CHD. Alternatively, in some embodiments, gaining accessto the CHD enables the third-party merchant 162 to perform a transactionwith or without viewing the CHD.

In one embodiment, the CHD access system 124 causes the CHD to bedisplayed to the user via one or more of the POS 166 and the computingsystem 164.

The CHD access system 124 can generally include any system that canprovide access to CHD associated with a token. In one embodiment, theCHD access system 124 authenticates a user and determines whether theuser is authorized to access the CHD before providing access to CHDassociated with a token.

The token access system 122, or the CHD access system 124, can log eachaccess of the CHD or token at the CHD access log repository 136, whichis part of the tokenization provider repository system 130.Advantageously, in some embodiments, by logging each access of the CHDor token, it can be determined if a potential unauthorized use of theCHD is attributable to the merchant 142, the third-party merchant 162,or some unrelated party.

The POS 166 can generally represent any point-of-sale system that canprocess payment card transactions by communicating with the credit cardprocessor 174. In one embodiment, the POS 166 communicates directly withthe credit card processor 174. Alternatively, the POS 166 communicateswith the credit card processor 174 via the network 170. The POS 166 mayalso communicate with the credit card processor 174 or the credit cardprocessors 172 using the tokenization provider system 102. Generally,this communication may occur if the third-party merchant environment 106is also a customer of the tokenization provider system 102. However, insome instances, the POS 166 may use the tokenization provider system 102to communicate with the credit card processors without the third-partymerchant environment 106 being a customer of the tokenization providersystem 102. For example, in some cases the third-party merchant 106 maybe authorized to use the tokenization provider system 102 wheninitiating transactions that use CHD associated with a token provided bya party that is a customer of the tokenization provider system 102, suchas the merchant environment 104. In one embodiment, the POS 166 and thePOS 144 can be similarly configured.

The gateway 126 can generally include any system that can processtransactions by providing CHD and transaction information to the creditcard processors 172 either directly or via the network 170 on behalf ofthe merchant environment 104.

The computing systems 146 and 164 can generally include any computingdevice(s), such as desktops, laptops, and wireless mobile devices (e.g.smart phones, PDAs, tablets, or the like), to name a few. In oneembodiment, one or more of the merchant environment 104 and thethird-party merchant environment 106 is associated with an ecommercewebsite. In one embodiment, the computing systems 146 and 164 can alsoinclude video game platforms, television set-top boxes, televisions(e.g., internet TVs), and computerized appliances, to name a few. In oneembodiment, the computing systems 146 and 164 can include any computingdevice that can interact with the tokenization provider system 102.

In one embodiment, providing access to a token and the CHD associatedwith the token comprises associating an authorization factor with thetoken. For example, to provide the third-party merchant 162 with accessto the CHD, the merchant 142 can send the token and a merchantidentifier associated with the third-party merchant 162 to the tokenaccess system 122. The token access system 122 can use the authorizationfactor generator 128 to generate an authorization factor. Theauthorization factor can be associated with the token and the merchantidentifier at the token access repository 134. The token access system122 can provide the authorization factor along with the token ortoken-identifier to the third-party merchant 162 enabling thethird-party merchant 162 to access the CHD associated with the token atthe tokenization provider system 102. In one embodiment, the merchant142 provides the authorization factor to the third-party merchant 162.

The authorization factor generator 128 can generally include any systemcapable of generating or otherwise accessing an authorization factor.The authorization factor can include any factor that can be used to helpauthenticate the third-party merchant 162 and to prevent automatedsystems, possibly associated with malicious users, from attempting toobtain CHD access. For example, the authorization factor can comprise aset of one or more random or pseudo-random words, numbers, symbols,images, sounds, or a combination of the same. In some embodiments, theauthorization factor can be non-random and may be associated with adefined algorithm. Further, in some embodiments, the authorizationfactor can be associated with a theme. For example, the authorizationfactor can be a set of four random color words, car images, or rockmusic sound bites. In some embodiments, the authorization factor can bea security question. In some cases, the authorization factor can be inone or more languages. Further, in some cases, the words may be sets ofrandom characters that may or may not spell a word as understood by, forexample, the merchant 162.

In one embodiment, to access CHD associated with a token, thethird-party merchant 162 authenticates with the tokenization providersystem 102. The third-party merchant 162 also provides both a token ortoken identifier and an authorization factor. If the authorizationfactor matches an authorization factor associated with the token and thetoken is associated with the third-party merchant 162, then the CHDaccess system 124 can provide the third-party merchant 162 with accessto the CHD associated with the token. Thus, in some embodiments, thethird-party merchant 162 must be registered with the tokenizationprovider system 102, and have been granted access to the CHD by themerchant 142.

In one embodiment, the admin 148 identifies the merchants, or users, tothe tokenization provider system 102 that the merchant 142 canpotentially provide token access. In one embodiment, the admin 148identifies to the tokenization provider system 102 the employees of themerchant environment 104 that can share token access with othermerchants, or users.

In one embodiment, the authorization factor is presented to thethird-party merchant 162 via a human-detection test, such as a captcha,reverse Turing test, or other challenge-response test. In oneembodiment, the authorization factor is presented to the third-partymerchant via a RSA hardware authenticator. In one embodiment, afterproviding the authorization factor, a phone-verification system (notshown) associated with the tokenization provider system 102 can contactthe third-party merchant 162 to request verification that thethird-party merchant 162 is attempting to access the CHD associated witha token. In some embodiments, use of the phone-verification system canadvantageously prevent attempts at automated CHD access by maliciousprograms.

In one embodiment, one or more of the token access system 122, the CHDaccess system 124, and the authorization factor generator 128 can belocated at the merchant environment 104.

As one example, non-limiting, use-case of an embodiment of the presentdisclosure, assume that the merchant environment 104 represents anelectronics store and the third-party merchant environment 106represents an extended warranty provider. The extended warranty provideris contracted with the merchant environment 104 to provide extendedwarranties to customers of the merchant environment 104 who opt topurchase an extended warranty with their electronic purchase. A customerwho is attempting to purchase a television may provide CHD to themerchant environment 104. The merchant environment 104 may then providethe CHD to the tokenization provider system 102. The tokenizationprovider system 102 processes the transaction and returns a tokenassociated with the CHD to the merchant environment 104 which stores thetoken and associates the token with the customer. Now, assume thecustomer decides to purchase the extended warranty for the television.The merchant environment 104 can authorize the third-party merchantenvironment 106 to use the token. The third-party merchant environment106 can then access the tokenization provider system 102 and request theCHD associated with the token, thereby enabling the third-party merchant106 to process the extended warranty transaction for the customer.Alternatively, the third-party merchant environment 106 can request thatthe tokenization provider system 102 process the extended warrantytransaction using the CHD associated with the token.

Example Token Provisioning Process

FIG. 2 illustrates a flow diagram for an example embodiment of a tokenprovisioning process 200. The process 200 can be implemented by anysystem that can generate and associate a token with CHD on behalf of amerchant 142 and can provide a second merchant, such as the third-partymerchant 162, with access to the token. For example, the process 200, inwhole or in part, can be implemented by one or more of the token accesssystem 122, the CHD access system 124, and the gateway 126. In oneembodiment, the second merchant can be a merchant that is associatedwith the merchant 142, such as an employee of the merchant 142. Althoughany number of systems, in whole or in part, can implement the process200, to simplify discussion, the process 200 will be described as beinggenerally implemented by the token access system 122.

The process 200 begins at block 202, where, for example, the tokenaccess system 122 receives CHD from the merchant 142. At block 204, thetoken access system 122 generates a token. This token can be any pieceof random or pseudo-random globally unique data that can be stored bythe merchant 142 in place of the CHD. In one embodiment, the token caninclude alphanumeric characters, symbols, pictures, sounds, video, etc.For example, the token may include a set of four words that may beEnglish words, words in any other language, or words from multiplelanguages. A user can provide the token to a system, such as the tokenaccess system 122, using a user interface configured according to thetype of token. For example, if the token includes a set of words, theuser interface may include a set of text fields. As a second example, ifthe token includes sounds, the interface may receive input from amusical keyboard or may map different keys on a computer keyboard todifferent sounds. Advantageously, in some embodiments, the keys that mapto the sounds may differ each time the user attempts to provide thetoken using the user interface thereby reducing the possibility that auser can learn a set of letters in place of the sound-based token.

In some cases, the token can be based on a theme. Advantageously, insome embodiments, using easily remembered tokens, such as English wordsassociated with a theme (e.g., animals, colors, etc.) facilitates a userremembering the token. As described in more detail below, such as withrespect to the process 300 of FIG. 3, accessing the CHD using the tokenmay require authentication of a user as well as determining the user'sauthorization to use the token. Thus, in some embodiments, using a tokenthat is designed to be relatively easy to remember does not reduce thesecurity benefits of tokenization. In some cases, the token may includemultiple types of data, e.g., the token could be any combination ofwords, images, sounds, or video. For example, the token may include aword, a set of random characters, and five musical notes. Generally,there exists no correlation between the token value or contents and thecontents of the CHD thereby making it impossible to determine the CHDfrom the token itself. However, in some embodiments, one or more piecesof the CHD can be used to facilitate generating the token. In oneembodiment, the token differs from an encrypted version of the CHD andthus, cannot be manipulated to obtain the CHD. In one embodiment, thetoken can be an encrypted form of the CHD or a combination of encryptedCHD and false non-CHD.

In some cases, the token may be formatted in a card-swipe compatibleformat. Further, in some cases, the token may be formatted to beprocessed by one or more systems (e.g., Point of Sale systems) as if thetoken were CHD. Moreover, the token may be configured to replace CHD ora Primary Account Number (PAN) included with the CHD with a surrogatevalue. Typically, this surrogate value is unique and is generated to notinclude a valid PAN or CHD.

In some embodiments, a single token exists at any given time per CHD.However, at different points in time, a different token may beassociated with a particular CHD. In some embodiments, the token is, atleast in part, algorithmically generated.

At block 206, the token access system 122 associates the token with theCHD. In some embodiments, the relationship between the token and the CHDis stored at the token/CHD relationship repository 132. In someembodiments, the token access system 122 may also associate the tokenwith the merchant 142. This relationship may also optionally be storedat the token/CHD relationship repository 132. In some cases, there mayexist a number of tokens and sets of CHD data. For example, there may beone, a hundred, a thousand, ten-thousand, a million, or more tokens andsets of CHD data. Thus, the token access system 122, for example, maymaintain relationships between a number of tokens and sets of CHD data,including, one, a hundred, a thousand, ten-thousand, etc. Generally, onetoken is associated with one set of CHD data. However, in someembodiments, a token may be associated with multiple sets of CHD dataand/or a set of CHD data may be associated with multiple tokens. Forexample, multiple merchants may have obtained a set of CHD from acustomer, and as a result, if more than one of the merchants usestokenization, it is possible for multiple tokens to be associated withone set of CHD.

At block 208, the token access system 122 provides the token to themerchant 142. In one embodiment, providing the token to the merchant 142enables the merchant to perform transactions without the CHD. Themerchant 142 can identify the token and provide transaction details, forexample, to the gateway 126 or the token access system 122. The gateway126 can then process the transaction on behalf of the merchant 142. Insome embodiments, the merchant 142 can store the token at the tokenrepository 152. Advantageously, in some embodiments, once the CHD hasinitially been provided to the token access system 122, the merchant 142can perform a transaction using the CHD without directly accessing,viewing, or maintaining a copy of the CHD at the merchant environment104.

At block 210, the token access system 122 receives a request toassociate the token with a second merchant, such as the third-partymerchant 162. In some embodiments, the request comprises receiving oneor more of an identifier, contact information, and account informationassociated with the third-party merchant 162. Generally, thisinformation does not include information that the third-party merchant162 uses to access the tokenization provider system 102. For example,the identifier or account information may include a public identifierthat the third-party merchant 162 can share with merchants who wish togrant the third-party merchant 162 with token access, but generally thepublic identifier is distinct from an identifier the third-partymerchant 162 uses to identify itself to the tokenization provider system162. However, in some embodiments, the public identifier and the loginidentifier may be the same. Further, in some embodiments, the requestcomprises receiving the identity of the token. Alternatively, therequest comprises receiving a copy of the token.

The token access system 122 authorizes the second merchant (e.g. thethird-party merchant 162) to access the token at block 212. In someembodiments, authorizing access to the token comprises authorizingaccess to the CHD. In some embodiments, block 212 can also compriseinforming the second merchant that the second merchant, or an accountassociated with the second merchant, is authorized to access the tokenand/or CHD. In some embodiments, informing the second merchant of theauthorization can comprise emailing, texting, leaving a voice message,or providing an alert via the POS 166, the computing system 164, or anaccount page associated with the third-party merchant 162 at thetokenization provider system 102. In some embodiments, authorizing thesecond merchant to access the token comprises providing a copy of thetoken and/or an identifier associated with the token to the secondmerchant. In some embodiments, the token access system 122 stores therelationship between the second merchant and the token and/or CHD at thetoken access repository 134.

Example Process for Accessing Cardholder Data

FIG. 3 illustrates a flow diagram for an example embodiment of a process300 for accessing cardholder data. The process 300 can be implemented byany system that can provide a second merchant, such as the third-partymerchant 162, with CHD associated with a token, which was created inresponse to a first merchant, such as the merchant 142, providing theCHD to the system or a related system. For example, the process 300, inwhole or in part, can be implemented by one or more of the token accesssystem 122, the CHD access system 124, and the gateway 126. In oneembodiment, the second merchant can be a merchant that is associatedwith the merchant 142, such as an employee of the merchant 142. In oneembodiment, the process 300 can be used by the merchant 142, whoinitially provided the CHD, or an employee of the merchant 142, toretrieve the CHD. Although any number of systems, in whole or in part,can implement the process 300, to simplify discussion, the process 300will be described as being generally implemented by the CHD accesssystem 124.

The process 300 begins at block 302, where, for example, the CHD accesssystem 124 receives user authentication information associated with, forexample, the third-party merchant 162. This user authenticationinformation can generally include any information that can be used toauthenticate the third-party merchant 162. For example, the userauthentication information can include: a user name, a password, a RSAtoken code (e.g. a code produced by an RSA SecurID™ hardwareauthenticator), and the response to a challenge-response test, such as ahuman-detection test response (e.g. a captcha response) or an answer toa security question.

At decision block 304, the CHD access system 124 determines, based atleast in part on the user authentication information, if the third-partymerchant 162 is authorized to access the tokenization provider system102, or any system associated with the tokenization provider system 102.If the third-party merchant 162 is not authorized to use thetokenization provider system 102, the CHD access system rejects thethird-party merchant 162 at block 306. In one embodiment, rejecting thethird-party merchant 162 can comprise initiating a registration processthat enables the third-party merchant 162 to register with thetokenization provider system 102. In one embodiment, rejecting thethird-party merchant 162 can comprise providing an error message to thethird-party merchant 162.

If the third-party merchant 162 is authorized to access the tokenizationprovider system 102, the CHD access system 124 receives a token from thethird-party merchant 162 at block 308. Alternatively, at block 308, theCHD access system 124 accesses the token pre-associated with thethird-party merchant 162 by the merchant 142 from the token accessrepository 134. In one embodiment, receiving the token comprisesreceiving a token identifier associated with the token. In oneembodiment, receiving the token includes receiving a request to accessCHD associated with the token.

At decision block 310, the CHD access system 124 determines if thethird-party merchant 162 is authorized to use the token. In oneembodiment, to determine if the third-party merchant 162 is authorizedto use the token, the CHD access system 124 determines if thethird-party merchant 162 is associated with the token at the tokenaccess repository 134.

If the third-party merchant 162 is not authorized to use the token, theCHD access system 124 rejects the third-party merchant's 162 request toaccess the CHD associated with the token at block 312. In oneembodiment, rejecting the third-party merchant's 162 request can includelogging the third-party merchant's 162 request at the CHD access logrepository 136. Further, in one embodiment, rejecting the third-partymerchant's 162 request can include informing the merchant 142 of thethird-party merchant's 162 attempt to use the token and/or access theCHD associated with the token. In one embodiment, in response to thethird-party merchant's 162 failed attempt to access the CHD, thetokenization provider system 102 can replace the token at thetokenization provider system 102 and the merchant environment 104 with anew token.

If the third-party merchant 162 is authorized to use the token, the CHDaccess system 124 provides access to CHD associated with the token atblock 314. In one embodiment, providing access to the CHD comprisesproviding the CHD to one or more of the POS 166 and the computing system164. In one embodiment, if given access to the CHD, the third-partymerchant 162 can view the CHD. Alternatively, the third-party merchant162 can initiate a transaction using the CHD at the POS 166, but withoutviewing the CHD. In one embodiment, providing access to the CHDcomprises the gateway 126 performing a transaction using the CHD onbehalf of the third-party merchant 162. In one embodiment, providing thethird-party merchant 162 with access to the CHD can include logging thethird-party merchant's 162 access of the CHD at the CHD access logrepository 136.

At block 316, the CHD access system 124 removes the third-partymerchant's 162 authorization to use the token, and consequently, thethird-party merchant's 162 authorization to access the CHD at thetokenization provider system 102. In one embodiment, removing thethird-party merchant's 162 authorization to use the token can comprisedisassociating the token and the third-party merchant 162 at the tokenaccess repository 134. In one embodiment, the threshold for removing thethird-party merchant's 162 authorization to use the token can be basedon any predetermined event. For example, authorization can be removedafter the third-party merchant 162 uses the token or accesses the CHD apre-determined number of times, such as once or five-times. As a secondexample, authorization can be removed after a pre-defined time period,such as 15-minutes from the time merchant 142 authorizes the third-partymerchant 162 to use the token, or 10-minutes from the time that thethird-party merchant 162 access the CHD using the token. In oneembodiment, block 316 is optional.

Second Example of a Token Provisioning Process

FIG. 4 illustrates a flow diagram for a second example embodiment of atoken provisioning process 400. The process 400 can be implemented byany system that can generate and associate a token with CHD on behalf ofa merchant 142 and can provide a second merchant, such as thethird-party merchant 162, with access to the token. For example, theprocess 400, in whole or in part, can be implemented by one or more ofthe token access system 122, the CHD access system 124, and the gateway126. In one embodiment, the second merchant can be a merchant that isassociated with the merchant 142, such as an employee of the merchant142. Although any number of systems, in whole or in part, can implementthe process 400, to simplify discussion, the process 400 will bedescribed as being generally implemented by the token access system 122.In some embodiments, the process 400 can be used to provide either athird-party merchant (e.g. the third-party merchant 162), or an employeeof the merchant 142 or the merchant environment 104 (e.g. the merchant142) with access to a token or CHD associated with the token. Tosimplify discussion, the process 400 will be described as being used toprovide the third-party merchant 162 with access to the token or CHDassociated with the token.

The process 400 begins at block 402, where, for example, the tokenaccess system 122 receives user authentication information associatedwith the merchant 142. This user authentication information can compriseany information necessary for the token access system 122 toauthenticate the merchant 142. For example, the user authenticationinformation can comprise a user name, a password, and a RSA token code,to name a few.

At decision block 404, the token access system 122 determines if themerchant 142 is authorized to grant a second merchant access to a token.In one embodiment, granting the second merchant access to the token caninclude granting the second merchant the ability to use the token toprocess a transaction. In one embodiment, decision block 404 comprisesdetermining if the merchant 142 is authorized to access one or more ofthe tokenization provider system 102, the token access system 122 andthe gateway 126. In one embodiment, the merchant 142 may have access tothe tokenization provider system 102 without having permission to accessall of the systems associated with the tokenization provider system 102.For example, the merchant 142 may have access to the gateway 126enabling the merchant 142 to process transactions for a customer, butmay not have access to the token access system 122 thereby preventingthe merchant 142 from providing token access to a second merchant. Inone embodiment, the admin 148 determines the merchant's 142 level ofaccess to the tokenization provider system 102. The admin 148 canconfigure an account associated with the merchant 142 and thetokenization provider system 102 to restrict the merchant's 142 level ofaccess to one or more of systems, tokens, and CHD associated with thetokenization provider system 102.

If the merchant 142 is not authorized to grant a second merchant accessto a token, the token access system 122 rejects the merchant 142 fromfurther accessing the token access system 122 at block 406. If themerchant 142 is authorized to grant token access to a second merchant,the token access system 122 receives the identity of a token from themerchant 142 at block 408. Receiving the identity of the token cancomprise receiving a token or receiving a token identifier associatedwith the token. Further, receiving the identity of the token may includereceiving a customer record that is associated with a token.Advantageously, in some embodiments, by providing a customer record (orportion thereof, such as a customer record identifier) that isassociated with a token to the token access system 122, the merchant 142can grant token access without knowing the token value, knowing that atoken exists, or having any understanding of how tokenization works.

In one embodiment, the token access system 122 verifies that themerchant 142 provided a token associated with the merchant 142 or themerchant environment 104. If the token is not associated with themerchant 142 or the merchant environment 104, the token access systemcan reject the token. In one embodiment, the token access system 122 canalso lock the merchant 142 out of the tokenization provider system 102,log the merchant's 142 actions at the CHD access log repository 130,report the access attempt to the admin 148, or combinations of the same.

At block 410, the token access system 122 receives the identity of thethird-party merchant 162, the user whom the merchant 142 wishes to granttoken access. In some embodiments, the token access system 122 receivesthe identity of the third-party merchant environment 106 or anorganization associated with the third-party merchant environment 106.In one embodiment, receiving the identity of the third-party merchant162 comprises receiving the identity of a merchant account associatedwith the tokenization provider system 102 and the third-party merchant162. As previously described, the identity can include any informationthat identifies the third-party merchant 162, or third-party merchantenvironment 106, to the tokenization provider system 102. This caninclude, for example, a unique identifier selected by the tokenizationprovider system 102 or the third-party merchant 162. As additionalexamples, the identifying information may include an e-mail address, aphone number, or any other contact information. Advantageously, in someembodiments, providing contact information as an identifier enables themerchant 142 to identify a third-party merchant 162 that has not yetregistered with the tokenization provider system 102 or without knowingthe third-party merchant's 162 unique identifier.

The token access system 122 may also receive a time-based or event-basedset of conditions associated with the third-party merchant 162 thatlimits the third-party merchant's 162 access to the CHD. For example,the conditions may limit the time-period in which the third-partymerchant 162 can access the CHD or the number of times the third-partymerchant 162 can access the CHD using the token. Further, in embodimentswhere the tokenization provider system 102 provides CHD access byperforming transactions on behalf of the third-party merchant 162, theconditions can include a monetary limit. Advantageously, in someembodiments, setting a monetary limit can prevent a third-party merchant162 from quoting one price to a customer or merchant 142 while charginga higher price once access to the CHD is obtained. The admin 148 mayalso pre-define the set of conditions such that each time the merchant142 provides a third-party merchant with CHD access, the set ofconditions are automatically associated with the CHD access.

At decision block 412, the token access system 122 determines if thethird-party merchant 162 is authorized to access tokens. Thisdetermination can comprise determining if the third-party merchant 162is registered with the tokenization provider system 102 and/or if thethird-party merchant 162 is authorized to access tokens associated withthe merchant environment 104. If the third-party merchant 162 is notauthorized to access tokens, the token access system 122 rejects themerchant selection of the third-party merchant 162 at block 414. In someembodiments, rejecting the merchant selection can comprise sending aregistration request to or initiating a registration process with thethird-party merchant 162. In some embodiments, rejecting the merchantselection can comprise requesting that the admin 148 authorize thethird-party merchant 162 to access tokens associated with the merchantenvironment 104, if so desired.

If the third-party merchant 162 is authorized to access tokens, thetoken access system 122 generates a set of random words at block 416using, for example, the authorization factor generator 128.Alternatively, the token access system 122 can generate any other typeof authentication factor using, for example, the authorization factorgenerator 128, as described above with respect to FIG. 1. At block 418,the set of random words are associated with the token identified atblock 408. At block 420, the set of random words are associated with thethird-party merchant 162. In one embodiment, the set of random words areassociated with a merchant account associated with the third-partymerchant environment 106. An employee associated with the third-partymerchant environment 106 that has access to the merchant account canthen use the set of random words and obtain access to the token andassociated CHD as described with respect to FIG. 5.

At block 422, the set of random words are provided to the third-partymerchant 162. In one embodiment, the set of random words can be providedby any type of communication. For example, the token access system 122can provide the set or random words by email, text, or voicemail, toname a few. In one embodiment, the set of random words are provided tothe merchant 142. The merchant 142 can then provide the set of randomwords to the third-party merchant 162. In one embodiment, performingblock 422 can further comprise performing block 212 as described withrespect to FIG. 2.

In one embodiment, the set of random words are provided in an encryptedformat to the third-party merchant 162. The third-party merchant 162 canthen decrypt the encrypted set of random words. In one embodiment, theset of random words can be provided in clear text. However, in someembodiments, because the set of random words are associated with thethird-party merchant 162, or the merchant account, at the tokenizationprovider system 102, malicious users are prevented from using the set ofrandom words to access the token and/or CHD associated with the token.

Second Example Process for Accessing Cardholder Data

FIG. 5 illustrates a flow diagram for a second example embodiment of aprocess 500 for accessing cardholder data. The process 500 can beimplemented by any system that can provide a second merchant, such asthe third-party merchant 162, with CHD associated with a token, whichwas created in response to a first merchant, such as the merchant 142,providing the CHD to the system or a related system. For example, theprocess 500, in whole or in part, can be implemented by one or more ofthe token access system 122, the CHD access system 124, and the gateway126. In one embodiment, the second merchant can be a merchant that isassociated with the merchant 142, such as an employee of the merchant142. In one embodiment, the process 500 can be used by the merchant 142,who initially provided the CHD, or an employee of the merchant 142, toretrieve the CHD. Further, the process 500 can be used by thethird-party merchant 162 to access CHD from any number of merchants whohave authorized the third-party merchant 162 to use their tokens.Although any number of systems, in whole or in part, can implement theprocess 500, to simplify discussion, the process 500 will be describedas being generally implemented by the CHD access system 124.

The process 500 begins at block 502, where, for example, the CHD accesssystem 124 receives user authentication information associated with thethird-party merchant 162. This user authentication information cangenerally include any information that can be used to authenticate thethird-party merchant 162. For example, the user authenticationinformation can include: a user name, a password, a RSA token code, andthe response to a challenge-response test, such as a captcha response oran answer to a security question.

At decision block 504, the CHD access system 124 determines, based atleast in part on the user authentication information, if the third-partymerchant 162 is authorized to access the tokenization provider system102, or any system associated with the tokenization provider system 102.In one embodiment, decision block 504 can include determining if thethird-party merchant 162 is registered with the tokenization providersystem 102. In one embodiment, decision block 504 can includedetermining if the merchant 142, or the admin 148, has provided thethird-party merchant 162 with access to tokens associated with themerchant 142 or the merchant environment 104.

If the third-party merchant 162 is not authorized to use thetokenization provider system 102, the CHD access system rejects thethird-party merchant 162 at block 506. In one embodiment, rejecting thethird-party merchant 162 can comprise initiating a registration processthat enables the third-party merchant 162 to register with thetokenization provider system 102. In one embodiment, rejecting thethird-party merchant 162 can comprise providing an error message to thethird-party merchant 162.

If the third-party merchant 162 is authorized to access the tokenizationprovider system 102, the CHD access system 124 receives a set of wordsfrom the third-party merchant 162 at block 508. Alternatively, oradditionally, the CHD access system 124 receives any authorizationfactor generated by the authorization factor generator 128 and providedto the third-party merchant 162 as part of the implementation of theprocess 400.

At decision block 510, the CHD access system 124 determines if the setof words received from the third-party merchant 162 match a set ofrandom words associated with a token. In one embodiment, the third-partymerchant 162 also identifies the token. Alternatively, the CHD accesssystem 124 identifies the token by determining if there exists any tokenassociated with a set of random words that match the received set ofwords and if so, the CHD access system 124 determines if the third-partymerchant 162 is authorized to access that token.

If the set of words received from the third-party merchant 162 do notmatch a set of random words associated with a token, the CHD accesssystem 124 rejects the third-party merchant 162 at block 506. Rejectingthe third-party merchant 162 can comprise causing an error message to bepresented to the third-party merchant 162. Further, in some embodiments,rejecting the third-party merchant 162 can cause an account associatedwith the third-party merchant 162 to be deactivated or suspended.

If the set of words received from the third-party merchant 162 matches aset of random words associated with a token, the CHD access system 124,at block 512, accesses the token associated with the set of random wordsat, for example, the tokenization provider repository system 130. Atblock 514, the CHD access system 124 obtains CHD associated with thetoken.

At block 516, the CHD access system 124 provides the third-partymerchant 162 with access to the CHD over a secure connection. In oneembodiment, the CHD is provided via the network 170. In one embodiment,the CHD is provided to the computing system 164 at block 516. Thecomputing system 164 can then provide the CHD directly to the POS 166and/or cause the CHD to be presented to the third-party merchant 162. Inone embodiment, the CHD is provided to the POS 166 at block 516. The POS166 can then provide the CHD to the credit card processor 174 tocomplete a transaction.

In one embodiment, providing the third-party merchant 162 with access tothe CHD can comprise the CHD access system 124 receiving transactioninformation associated with a requested transaction. The CHD accesssystem 124 can then provide the CHD and the transaction information tothe gateway 126, which can then process the transaction using the creditcard processors 172. Advantageously, in some embodiments, thethird-party merchant 162 is able to use the CHD without the CHD beingpresented to the third-party merchant 162. In one embodiment, a subsetof the CHD is presented to the third-party merchant 162 enabling thethird-party merchant 162 to log the transaction and/or to verify thatthe transaction is associated with the correct CHD or customer. In someembodiments, the CHD access system 124 may verify that the value of thetransaction does not exceed a pre-defined transaction-limit associatedwith the third-party merchant's 162 access of the CHD. If thetransaction-limit is exceeded, the CHD access system 124 can reject thetransaction. Further, the CHD access system 124 can report the attemptedtransaction to the merchant 142 or the admin 148. The CHD access system124 can also report successful transactions to the merchant 142 therebyenabling the merchant 142 to verify that the third-party merchant 162processed the transaction for the merchant's 142 customer.

In one embodiment, the CHD access system 124 logs each access and/orattempted access of the token and/or CHD at the CHD access logrepository 136. Advantageously, in some embodiments, if there is adisputed credit card use, the CHD access log repository 136 can beaccessed to determine what parties may have accessed the token and/orCHD around the time associated with the disputed credit card use.

At block 518, the CHD access system 124 disassociates the set of randomwords from the token and the third-party merchant 162. In oneembodiment, disassociating the set of random words can include deletingor removing the words from the tokenization provider system 102. In oneembodiment, block 518 is performed in response to the third-partymerchant 162 accessing the token and/or CHD. In one embodiment, block518 is performed in response to a pre-defined event. This pre-definedevent can include any event associated with the token and/or CHD. Forexample, the pre-defined event can comprise: the number of times the setof random words have been provided by the third-party merchant 162 tothe tokenization provider system 102 (e.g. once, or five times); thelength of time since the set of random words were associated with thetoken (e.g. 15-minutes); or the length of time since the third-partymerchant 162 first accessed the token and/or CHD, to name a few.

Further, in some embodiments, the CHD access system 124 may disassociatethe set of random words from the token without the third-party merchant162 having ever accessed or attempted to access the CHD. For example, ifthe pre-defined event is a time-limit or time-period, the CHD accesssystem 124 can disassociate the set of random words from the token atthe expiration of the time-limit or time-period whether or not thethird-party merchant 162 accessed the CHD. In addition, if the owner ofthe token (e.g. the merchant 142) ceases to trust the third-partymerchant 162, the token owner can access the tokenization providersystem 102 and remove the third-party merchant's 162 authorization toaccess the token, and thus the CHD associated with the token. Removingthe authorization to access the token may include disassociating the setof random words from the token prior to the pre-defined event occurring.

In one embodiment, the third-party merchant 162 can communicate with theCHD access system 124 using any secure system. For example, thethird-party merchant 162 can provide the user authentication informationor the set of random words using a secure portal or webpage associatedwith the tokenization provider system 102. Alternatively, thethird-party merchant 162 can use a virtual private network (VPN) or asecure application obtained from the tokenization provider system 102 toaccess the tokenization provider system 102 and to provide the userauthentication information or the set of random words to the CHD accesssystem 124.

Advantageously, in some embodiments, a merchant can use the process 200or 400 to reduce CHD misuse or the misappropriation of CHD by amalicious user because the CHD is not stored with the merchant. Further,in some embodiments, using the process 300 or 500, the merchant canprovide CHD to a third-party merchant who may not be a customer of thetokenization provider system or who may not be capable of interactingwith the tokenization provider system due to, for example, differing CHDprocessing systems or legal regulations in the third-party merchant'scountry or jurisdiction. Similarly, in some embodiments, the merchantcan use the process 300 or 500 to require CHD to complete a transactionwith a bank or credit card processor whose payment card processingsystems may not be capable of interacting with the tokenization providersystem.

Example Information Flow

FIG. 6 illustrates a flow diagram for an example flow 600 of informationusing a tokenization provider system 606. Some or all of the systemsdescribed herein can be used to facilitate the flow illustrated in FIG.6. For example, the interaction with the merchant 604 can be via acomputing system associated with the merchant 604. As a second example,interaction with the third-party merchant may be via a POS.

The flow 600 begins at event 1 with the customer 602 providing CHD tothe merchant 604. This CHD is then provided by the merchant 604 to thetokenization provider system 606 at event 2. At event 3, thetokenization provider system 606 generates a token and associates thetoken with the CHD. This token is provided to the merchant at event 4.Generally, but not necessarily, the merchant 604 can store the token inplace of the CHD and can destroy or not save any copies of the CHD thatthe merchant 604 received. In other embodiments, the merchant 604generates the token or at least a portion of the token instead of (or inaddition to) the tokenization provider system 606.

At event 5, the customer 602 provides a product or service request tothe merchant 604 for a product or service that may be provided by thethird-party merchant 608. For example, the request may be for operatickets, flowers, or for an appointment at a spa. At event 6, themerchant 604 authorizes the third-party merchant 608 to access the tokenat the tokenization provider system 606 by communicating theauthorization to the tokenization provider system 606. The tokenizationprovider system 606, at event 7, generates an authorization factor, suchas a set of four random words, and associates the third-party merchantwith the authorization factor and the token.

At event 8, the tokenization provider system 606 provides theauthorization factor to the merchant 604, such as by email or through aweb-portal. The merchant 604 provides the authorization factor and thecustomer's 602 product or service request to the third-party merchant608 at event 9. At event 10, the third-party merchant 608 authenticateswith the tokenization provider system 606. The third-party merchant 608also provides the authorization factor to the tokenization providersystem 606 at event 10. In some embodiments, authenticating andproviding the authorization factor may be two separate events.

Assuming that the third-party merchant 608 is authenticated and that thetokenization provider system 606 determines that the third-partymerchant 608 is authorized to access the token, the tokenizationprovider system 606 provides access to the CHD associated with the tokenat event 11. In some embodiments, providing access to the CHD mayinclude providing the CHD to the third-party merchant 608.

The flow of information illustrated in FIG. 6 is for illustrativepurposes and is not intended to be limiting. For example, in some cases,instead of, or in addition to, the tokenization provider system 606providing the authorization factor to the merchant 604 at event 8, thetokenization provider system 606 can provide the authorization factor tothe third-party merchant 608.

Examples of CHD Interface Screens

FIGS. 7-12 illustrate several non-limiting embodiments of interfacescreens that can be electronically generated by one or more of thetokenization provider system 102, the token access system 122, or anyother system that can regulate the access of CHD associated with atoken. Although the interface screens are illustrated as Graphical UserInterfaces (GUIs), the interface screens are not limited as such. Forexample, the interface screens can include command-line interfaces(CLIs), three-dimensional interfaces, or a combination of interfacetypes.

A user, such as the third-party merchant 162, can access the interfacescreens illustrated in FIGS. 7-12 using a POS 166, a computing system164, or the like. In some embodiments, some or all of the interfacescreens may be included as part of a web-based or Internet-basedsoftware application that is accessed via a network 170. Alternatively,some or all of the interface screens may be part of a client-sidesoftware application stored locally, such as on the computing system164, which can communicate over the network 170 with a server-sideapplication stored on, for example, the token access system 122.

FIG. 7 illustrates an embodiment of a user login interface 700. In someembodiments, the user login interface 700 enables a user (e.g. thethird-party merchant 162) who desires to access CHD associated withanother user's token (e.g. the merchant 142 or organization associatedwith the merchant 142) to access the token access system 122. In someembodiments, users who desire to provide token access to another party(e.g. a user or organization) can use the user login interface 700 toaccess the token access system 122. The third-party merchant 162 canprovide a user name and password using the login panel 702 toauthenticate with the token access system 122. Other authenticationmechanisms are possible. For example, the login panel 702 can presentthe third-party merchant 162 with an opportunity to present a uniquecryptographic identifier or key. This key, in certain embodiments, canthen be matched to or decrypted with a corresponding public key toauthenticate the third-party merchant 162.

The user login interface 700 includes a registration link 704. Thisregistration link 704 can be used to direct an unregistered user to aregistration screen, such as the user registration interface 800depicted in FIG. 8. Further, the user login interface 700 can alsoinclude a login link 706 that can be used to direct a user (e.g. themerchant 142) who is registered with the tokenization provider system102 to another login interface. This additional login interface can beuser by subscribers of the tokenization provider system 102 to managetoken access, such as to grant token access to third-party merchantorganizations and/or users.

FIG. 8 illustrates an embodiment of a user registration interface 800.The user registration interface 800 enables a user to register with thetoken access system 122 by providing, for example, contact information,a username, and a password. The user registration interface 800 can beused, for example, by the third-party merchant 162 of FIG. 1, who maynot necessarily be a customer of the provider of the tokenizationprovider system 102. By registering with the token access system 122, insome embodiments, the third-party merchant 162 can access CHD associatedwith tokens that have been associated with the third-party merchant 162or the third-party merchant environment 106 by the user who is acustomer of the organization associated with the tokenization providersystem 102.

In some embodiments, a merchant 142 or an organization associated withthe merchant environment 104 that is a customer of the organizationassociated with the tokenization provider system 102 can use the userregistration interface 800 to register an account with the token accesssystem 122. Advantageously, in certain embodiments, this enablesmerchants to share access to CHD and/or tokens with other merchantswhether or not the other merchants are customers of the tokenizationprovider system 102.

FIG. 9 illustrates an embodiment of a merchant selection interface 900.The merchant selection interface 900 enables a user (e.g. thethird-party merchant 162) to select or connect to another user orassociated organization (e.g. a merchant 142, a merchant environment104, or an organization associated with the merchant environment 104)that has provided token access to the user or an organization associatedwith the user (e.g. the user's employer). For example, the third-partymerchant 162 can use the merchant selection interface 900 to select theorganization associated with the merchant environment 104. In someembodiments, the third-party merchant 162 can select the merchantenvironment 104. For example, if the merchant organization is a hotelchain, the third-party merchant 162 can select a specific franchise,location, or branch of the hotel chain using the merchant selectioninterface 900.

In some embodiments, the merchant selection interface 900 enables thethird-party merchant 162 to select any organization (or user) registeredwith the tokenization provider system 102. Alternatively, the merchantselection interface 900 may be configured to enable the third-partymerchant 162 to select organizations (or users) that are currentlysharing a token with the third-party merchant 162. In some cases, thethird-party merchant 162 may be able to select any organization (oruser) that has shared a token with the third-party merchant 162 at somepoint, whether or not the organization is currently sharing a token withthe third-party merchant 162.

The merchant selection interface 900 can include an existing connectionspanel 902. The existing connections panel 902 can list some or all ofthe users or organizations with whom the third-party merchant 162 iscurrently connected. In some embodiments, the existing connections panel902 may list organizations that are sharing a token with the third-partymerchant 162. Alternatively, the existing connections panel 902 may listany organization with which the third-party merchant 162 has establisheda connection. In some embodiments, the third-party merchant 162 canselect organizations with which to connect. For some embodiments,organizations that are sharing tokens with the third-party merchant 162(or an associated organization) are automatically connected to thethird-party merchant 162 and may automatically be listed on the existingconnections panel 902.

The existing connections panel 902 can list connections in any order.For example, the existing connection panel 902 may list theorganizations that are currently sharing a connection before displayingother connections. Alternatively, for example, organizations may belisted in alphabetical order, by frequency of access, or based on whenthe organization was added to the list.

In some implementations, the merchant selection interface 900 caninclude one or more search fields 904 for locating organizations thatmay have shared a token with the third-party merchant 162 (or anassociated organization). These search fields 904 can include, forexample, a name field, a city field, an address field, or a product orservice field (e.g. electronics, hospitality, restaurants, etc.), toname a few. In some cases, the search fields 904 may be used to searchfor an organization that is known to the tokenization provider system102 or that has registered with the tokenization provider system 102.

The results list 906 can list the organizations identified based on theinformation supplied to the search fields 904. Although illustrated as adrop-down list, the results list 906 is not limited as such and mayinclude any type of GUI element, or other interface element, fordisplaying the list of results. For example, the results list 906 mayinclude a dialog box, pop-up dialog box, a combo box, or other GUIelement.

FIG. 10 illustrates an example embodiment of a populated merchantselection interface 1000. The populated merchant selection interface1000 is substantially similar to the merchant selection interface 900.However, the search fields 904 and the results list 906 of the populatedmerchant selection interface 1000 illustrate sample search informationand sample results respectively.

FIG. 11 illustrates an example embodiment of a CHD access interface1100. The CHD access interface 1100 enables the third-party merchant 162(or other user) to access CHD associated with a token that has beenshared with the third-party merchant 162 or an associated organizationof the third-party merchant 162. To access the CHD, in certainembodiments, the third-party merchant 162 can provide an authorizationfactor associated with the token that is associated with the CHD. As haspreviously been described, the authorization factor can be, for example,a set of four words. Further, the third-party merchant 162 can providethe authorization factor via authorization fields 1102. Authorizationfields 1102 can include any GUI element for providing the authorizationfactor including, for example, a GUI element that allows for theuploading of an authentication file, such as a cryptographic keyassociated with the third-party merchant 162. In the illustratedembodiment, the authorization fields 1102 include four text fields forentering the authorization factor.

The CHD access interface 1100 may also include a challenge-responsemechanism 1104. This challenge-response mechanism 1104 can include anymechanism for preventing automated systems, such as Internet bots, fromaccessing CHD using the CHD access interface 1100. For example, thechallenge-response mechanism can include a security question, aCompletely Automated Public Turing test to tell Computers and HumansApart (CAPTCHA) (as illustrated in FIG. 11), combinations of the same,or the like.

FIG. 12 illustrates an example of a CHD provisioning interface 1200. TheCHD provisioning interface 1200 can present CHD via CHD fields 1204 to auser, such as the third-party merchant 162. Further, the CHDprovisioning interface 1200 can include a timer 1202 that identifies howmuch time is remaining for the third-party merchant 162 to access theCHD before the CHD is cleared from the CHD provisioning interface 1200.

In some embodiments, the CHD provisioning interface 1200 includes GUIfields for specifying a transaction. Advantageously, in certainembodiments, the tokenization provider system 102 can perform thetransaction for the third-party merchant 162. Thus, in some embodiments,the CHD provisioning interface 1200 may not present the CHD to thethird-party merchant 162. However, the CHD provisioning interface 1200may present the status of the transaction, including a confirmationvalue.

Second Example Token-Sharing Environment

FIG. 13 illustrates an example embodiment of a token-sharing environment1300. The token-sharing environment 1300 illustrates an exampleembodiment of merchant environments managing, at least in part, theirown token access systems. Further, the token-sharing environment 1300illustrates an example of a third-party merchant environment 1306accessing tokens from other merchant environments (e.g., the merchantenvironment 1304). Reference numbers from FIG. 1 are re-used to indicatecorrespondence between referenced elements in FIG. 1 and in FIG. 13 and,to simplify discussion, descriptions of these corresponding elements arenot repeated with respect to FIG. 13.

Similar to the token-sharing environment 100, the token-sharingenvironment 1300 can include a tokenization provider system 1302, amerchant environment 1304, and a third-party merchant environment 1306.Further, the token-sharing environment 1300 may include one or moremerchant environments 1380. In addition, although not depicted, thetoken-sharing environment 1300 may include a number of credit cardprocessors.

Although FIG. 13 does not illustrate any systems or subsystemsassociated with the tokenization provider system 1302, in certainembodiments, the tokenization provider system 1302 may include some orall of the systems included by the tokenization provider system 102.Further, the tokenization provider system 1302 may include some or allof the embodiments described above with relation to the tokenizationprovider system 102. Similarly, the merchant environment 1304 and thethird-party merchant environment 1306 may each include some or all ofthe embodiments described above with relation to the merchantenvironment 104 and the third-party merchant environment 106.

The one or more merchant environments 1380 may include any number ortype of systems and configurations. In some cases, some or all of themerchant environments 1380 may include at least some systems andconfigurations associated with the merchant environment 104, themerchant environment 1304, the third-party merchant environment 106,and/or the third-party merchant environment 1306. Further, at least someof the merchant environments 1380 may use tokenization, or include atoken access system or other system associated with accessing and/orsharing tokens.

In some embodiments, a merchant 142 associated with the merchantenvironment 1304 may obtain a token for a set of CHD. The merchant 142may obtain this token by, for example, swiping a credit card through thePOS 144 or entering CHD into the POS 144, which is then provided to atokenization system (e.g., the tokenization provider system 1302), whichprovides the token to the merchant 142, or to a system associated withthe merchant environment 1304 (e.g., the POS 144 or the token repository152).

The merchant 142, using for example the token access system 1322, maycause the token to be associated with the third-party merchantenvironment 1306 and/or one or more of the merchant environments 1380.Associating the token with the third-party merchant environment 1306 mayoccur in response to a request from the third-party merchant 162, oranother employee of the third-party merchant 1306, or in response to arequest from a customer of the merchant environment 1304 who, forexample, may be considering using the services of the third-partymerchant environment 1306. Advantageously, in some embodiments, bysharing the token with the third-party environment 1306, the customer oran employee of the merchant environment 1304 can purchase products orservices from the third-party merchant environment 1306 withoutaccessing the CHD. In some cases, associating the token with thethird-party merchant environment 1306 may occur in response to a requestby the merchant 142. Advantageously, in certain embodiments, themerchant 142 can cause the token to be associated with the third-partymerchant environment 1306 before, or without, the third-party merchant162 requesting access to the token.

Associating the token with the third-party merchant environment 1306 caninclude generating an authorization factor using, for example, theauthorization factor generator 1328. Once the authorization factor isgenerated, it may be provided to the third-party merchant 162 under thecontrol of the merchant 142, or in response to the merchant 142associating the token with the third-party merchant environment 1306. Insome embodiments, the authorization factor generator 1328 can includesome or all of the features described above with respect to theauthorization factor generation 128.

In some situations, the third-party merchant 162 may require access tothe CHD associated with the token. For example, the third-party merchant162 may want access to the CHD before completing a transaction toprovide a service or product to a customer of the merchant 142. Asdescribed previously, in some cases, accessing the CHD may includeobtaining the CHD. In some cases, accessing the CHD may include theability to use the CHD, but may or may not include obtaining the CHD orhaving the ability to view the CHD. Although in some cases the inabilityto view the CHD prevents a merchant from viewing all the CHD, in manycases at least some of the CHD may be viewable. For example, althoughthe third-party merchant 162 may not be able to view an account number,the third-party merchant 162 may be able to view the name of thecardholder.

To use or access the CHD, the third-party merchant 162 may use thecomputing system 1364 to communicate with a token access system 1322associated with the merchant environment 1304. In some cases, thecomputing system 1364 may include a token access client 1390. In othercases, the token access client 1390 may be implemented as a separatesystem from the computing system 1364. For some cases where the tokenaccess client 1390 is a separate system, the third-party merchant 162may access the token access client 1390 directly. In other cases, thethird-party merchant 162 may access the token access client 1390 via thecomputing system 1364.

The computing system 1364 can generally include any type of computingsystem. In some implementations, the computing system 1364 may be ageneral purpose computing system, such as a desktop, laptop, or tablet,which may include the functionality of the CHD access system 1324 and/orthe token access client 1390 through, for example, a softwareapplication or a hardware add-on (e.g., a dongle, an expansion card, ora USB connectable device). In other implementations, the computingsystem 1364 may be a special purpose computing system which may includeone or more hardware or software modules configured to provide thefunctionality of the CHD access system 1324 and/or the token accessclient 1390. In some embodiments, the computing system 1364 can includesome or all of the features described above with respect to thecomputing systems 146 and 164.

The token access client 1390 can generally include any system that iscapable of identifying a token source for obtaining access to a tokenassociated with CHD. For example, the token source may include themerchant environment 1304 or the tokenization provider system 1302. Insome cases, the token access client 1390 may identify the token sourcebased on the authorization factor provided to the third-party merchantenvironment 1306 by the merchant environment 1304 using, for example,the token access system 1322. In other cases, the third-party merchant162 may configure the token access client 1390 with the identity of thetoken source. In some cases, the token access system 1322 may identifythe merchant environment 1304 as the token source when providing theauthorization factor to the third-party merchant 162 or the third-partymerchant environment 1306.

Using the token access client 1390, the third-party merchant 162 mayrequest access to a token from the merchant environment 1304. Thisrequest may be provided to the token access system 1322. The tokenaccess system 1322 can include any system that can generate tokens andprovide access to the tokens to a merchant or employee of a merchantenvironment including the third-party merchant environment 1306. Asillustrated, the token access system 1322 may be located at the merchantenvironment 1304 in its entirety. However, in some cases, the tokenaccess system 1322 may be a distributed system. Further, in some cases,the token access system 1322 may be split between the merchantenvironment 1304 and the tokenization provider system 1302. In someimplementations, the token access system 1322 may represent a thinclient, which can provide an Application Programming Interface (API) orany other type of interface for accessing a third-party token accesssystem, which may be hosted by another merchant environment, atokenization provider system 1302, a token hosting service provider (notshown), or any other system that can store and/or regulate access totokens. In some embodiments, the token access system 1322 can includesome or all of the features described above with relation to the tokenaccess system 122. The token access system 1322 can include anauthorization factor generator 1328, which, as described above, canprovide an authorization factor associated with a token. In someembodiments, the token access client 1390 may determine the merchantenvironment, or token access system of the merchant environment, tocontact based on one or more of an authorization factor, a merchantidentifier, or indication of the third-party merchant 162. Thus, thetoken access client 1390 can determine whether to communicate with thetoken access system 1322 or a token access system associated with one ofthe merchant environments 1380.

As part of the request to access the token from the merchant environment1304, or in response to a prompt from the token access system 1322, thethird-party merchant 162 may provide an authorization factor to thetoken access system 1322. If the token access system determines that thethird-party merchant 162, or another employee of the third-partymerchant environment 1306, is authorized to access the token, the tokenaccess system 1322 may provide the token to the third-party merchantenvironment 1306. The third-party merchant 162 can then use the CHDaccess system 1324 to access CHD associated with the token. Accessingthe CHD can include the CHD access system 1324 providing the receivedtoken to the tokenization provider system 1302 and requesting access tothe associated CHD. The tokenization provider system 1302 may thenprovide the third-party merchant 162 with access to the CHD associatedwith the token. As previously described, providing access to the CHD caninclude providing the CHD to the third-party merchant 162 or enablingthe third-party merchant 162 to complete a transaction using the CHDwith or without providing the CHD to the third-party merchant 162.

In some embodiments, the token access system 1322 may include the CHDaccess system 1324. In some cases, in response to the request to accessthe token, the token access system 1322 may use the CHD access system1324 to obtain access to the CHD on behalf of the third-party merchant1306. The third-party merchant 162 can provide transaction details, suchas the price of a product, to the token access system 1322 at themerchant environment 1304, and the token access system 1322 can completethe transaction for the third-party merchant environment 1306 andprovide a confirmation to the third-party merchant 162. In someembodiments, the CHD access system 1324 can include some or all of thefeatures described above with respect to the CHD access system 124.

In some embodiments, some or all of the process 200 and/or the process400 may be performed by a system associated with the merchantenvironment 1304 to associate a token with the third-party merchantenvironment 1306. For example, in some embodiments, the token accesssystem 1322 may be configured to perform one or more of the operationsassociated with the process 200 and/or the process 400. For instance,the token access system 1322 may receive a request to associate a tokenwith the third-party merchant environment 1306. If the third-partymerchant environment 1306 is authorized to access the tokens of themerchant environment 1304, the token access system 1322 may generate aset of random words, or some other authorization factor, and associatethe set of random words with the token and the third-party merchantenvironment 1306, or an employee thereof (e.g., the third-party merchant162). The token access system 1322 can then provide the set of randomwords to the third-party merchant environment 1306 or the third-partymerchant 162.

Example Process for Accessing a Token

FIG. 14 illustrates a flow diagram for an example embodiment of aprocess 1400 for accessing a token. The process 1400 can be implementedby any system that can provide a second merchant, such as thethird-party merchant 162, with access to a token created in response toa first merchant, such as the merchant 142, providing CHD to atokenization system. For example, the process 1400, in whole or in part,can be implemented by one or more of the token access system 1322, thecomputing system 146, and the tokenization provider system 1302.Although any number of systems, in whole or in part, can implement theprocess 1400, to simplify discussion, the process 1400 will be describedas being generally implemented by the token access system 1322.

The process 1400 begins at block 1402 where, for example, the tokenaccess system 1322 receives a set of words from a user (e.g., thethird-party merchant 162) associated with the third-party merchantenvironment 1306. The token access system 1322 can compare the receivedset of words to a set of words associated with tokens stored at thetoken repository 152 to determine if the user is authorized to accessone or more of the tokens. Although the process 1400 is described withrespect to a set of words, it is possible to perform the process 1400using any type of authorization factor including those previouslydescribed above. Further, in some cases, multiple checks may beperformed. For instance, the process 1400 can include determiningwhether a password matches a user, and if so, the process 1400 can theninclude a token identification check based on, for example, a set ofwords, as described above.

In some embodiments, the block 1402 includes authenticating the user.Authenticating the user may also include determining whether the user orthe third-party merchant environment 1306 is authorized to provide theset of words or to access the tokens of the merchant environment 1304associated with the token access system 1322. Some embodiments forauthenticating the user and for determining the user's authorization aredescribed above with respect to the blocks 502 and 504.

At decision block 1404, the token access system 1322 determines whetherthe set of words match a set of random words associated with a token. Ifthe set of words do not match the set of random words, the token accesssystem 1322 rejects the user, or the user's request to access the token,at the block 1406. In some embodiments, the decision block 1404 caninclude some or all of the embodiments described above with respect tothe decision block 510. Further, in some embodiments, the block 1406 caninclude some or all of the embodiments described above with respect tothe block 506.

If the token access system determines that the set of words match a setof random words associated with the token, the token access system 1322can provide the user with the token associated with the set of randomwords at block 1408. In some cases, the block 1408 may further includedetermining whether the token is associated with the user prior toproviding the user with the token. In some embodiments, the block 1408may include providing the user with access to the token with or withoutproviding the user with the token. For example, the token access system1322 may inform the user that the user has obtained access to the tokenand that in response to the user providing transaction details, thetoken access system 1322 can complete the transaction for the user usingthe token. Advantageously, in certain embodiments, the third-partymerchant 162 can complete a transaction using a token and CHD associatedwith the token without ever viewing or accessing the token or CHD.

At block 1410, the token access system can disassociate the set ofrandom words from the token and the user. In some cases, the block 1410can include disassociating the token with the user (e.g., thethird-party merchant 162). In certain embodiments, some or all of theembodiments described above with respect to the block 518 may apply tothe block 1410.

Third Example Process for Accessing Cardholder Data

FIG. 15 illustrates a flow diagram for a third example embodiment of aprocess 1500 for accessing cardholder data. The process 1500 can beimplemented by any system that can provide a second merchant (e.g., thethird-party merchant 162) with access to CHD associated with a token,which was created in response to a first merchant (e.g., the merchant142) providing the CHD to the system or a related system. For example,the process 1500, in whole or in part, can be implemented by one or moreof the CHD access system 1324, the token access client 1390, thecomputing system 1364, the token access system 124, and the token accesssystem 1322. Although any number of systems, in whole or in part, canimplement the process 1500, to simplify discussion, the process 1500will be described as being generally implemented by the computing system1364.

The process begins at block 1502 where, for example, the computingsystem 1364 at the third-party merchant environment 1306 using, forexample, the token access client 1390 provides a set of words to a tokenaccess system 1322 hosted by the merchant environment 1304. In certainembodiments, the block 1502 may be part of an authentication process foraccessing the token access system 1322. Examples of authenticationelements and processes that may be used herein are described in “TheOAuth 2.0 Authorization Protocol draft-ietf-oauth-v2-25,” dated Mar. 8,2012, located at http://tools.ietf.org/html/draft-ietf-oauth-v2-25 (lastaccessed Mar. 23, 2012) and is hereby incorporated by reference hereinin its entirety. In other embodiments, the block 1502 may include anauthentication process for authenticating the third-party merchant 162.The set of words may then be used to identify the specific token to beaccessed.

In some embodiments, the block 1502 may include a process fordetermining the token access system and/or merchant environment toaccess or to provide the set of words. In some cases, determining themerchant environment to access is based on the set of words. In othercases, the merchant environment is selected by the third-party merchant162. Alternatively, the merchant environment is preselected by, forexample, an administrator. In some cases, the process 1500 may beperformed in response to a system hosted by the merchant environment1304, such as the token access system 1322, communicating with a systemhosted by the third-party merchant environment 1306, such as thecomputing system 1364. In some cases, the merchant environment may beselected via merchant specific identifiers, such as a merchant accountnumber. The merchant account number may be specified by a userassociated with the third-party merchant environment 1306 (e.g., thethird-party merchant 162). Alternatively, the merchant account numbermay be associated with the set of words or provided by the merchant whoprovided the set of words to the third-party merchant environment 1306.

At block 1504, the computing system 1364 receives a token associatedwith a set of cardholder data from the token access system 1322. In someembodiments, receiving the token may include receiving a copy of thetoken. Alternatively, or in addition, receiving the token may includereceiving access to the token and/or permission to use the token, but insome embodiments does not include receiving a copy of the token.Advantageously, in certain embodiments, the third-party merchant 162 canuse the token without the token being transmitted from the merchantenvironment 1304, or a system associated with the merchant environment1304, to the third-party merchant environment 1306.

At block 1506, the computing system 1364 using, for example, the CHDaccess system 1324 may provide the token to a tokenization providersystem 1302 to obtain access to the CHD associated with the token. Atblock 1508, the computing system 1364 may receive access to the CHD fromthe tokenization provider system 1302. In some cases, receiving accessto the CHD may include receiving a copy of the CHD. The copy of the CHDmay include an encrypted copy of the CHD, which may be decrypted by, forexample, the CHD access system 1324. In other cases, receiving access tothe CHD may include obtaining permission to use the CHD at thetokenization provider system 1302. In such cases, the third-partymerchant 162 using, for example, the computing system 1364 or POS 166may provide transaction details to the tokenization provider system1302. The tokenization provider system 1302 may then complete thetransaction on behalf of the third-party merchant 162. Advantageously,in some embodiments, the third-party merchant 162 can complete atransaction using the CHD without obtaining a copy of the CHD.

In some embodiments, the third-party merchant 162 may provide thetransaction details to, for example, the token access system 1322 hostedby the merchant environment 1304. The token access system 1322 may thenprovide the transaction details and the token to the tokenizationprovider system 1302, which may complete the transaction on behalf ofthe third-party merchant 162. Advantageously, in some embodiments, thethird-party merchant 162 can complete a transaction using the CHDwithout ever obtaining a copy of the CHD or the token associated withthe CHD.

Example of a Token Access System

FIG. 16 illustrates an example embodiment of a token access system 1622.The token access system 1622 can include any type of system that can beused by a tokenization provider system (e.g., the tokenization providersystem 102) or a merchant environment (e.g., the merchant environment1304) to provide a user or merchant with access to a token and/or CHDassociated with a token. In some embodiments, the token access system1622 can include some or all of the embodiments described above withrespect to the token access system 122 and/or the token access system1322.

The token access system 1622 can include an authorization factorgenerator 128, a CHD access system 124, and an interactive voiceresponse (IVR) system 1630. The authorization factor generator 128 andthe CHD access system 124 of token access system 1622 can include someor all of the embodiments previously described with respect to theauthorization factor generator 128 and the CHD access system 124.

The IVR system 1630 can include any system that enables a user tointeract with the token access system 1622 using voice input. The voiceinput can include voice commands as well as any information or data thatcan be provided by voice. Further, the IVR system 1630 can prompt a userto provide commands and/or data via an audio prompt. Although configuredfor voice input and audio output, in some embodiments, the IVR system1630 can be configured to interact with a user via other methods andmechanisms. For example, in some cases, the IVR system 1630 can be aninteractive voice and video response (IWR) system capable of interactingwith a user via both voice and video. In some cases, the IVR system 1630can interact with the user via static images and/or an interactive userinterface, which may include audio, video, or images.

A user can use one or more of a telephone, dumbphone, a feature phone, asmartphone, and a computing device (e.g., a laptop, desktop, tablet,etc.) to interact with the IVR system 1630. For example, a user can usea system or service that utilizes Voice over Internet Protocol (VoIP) tointeract with the IVR system 1630. Further, in some embodiments, acomputer or computing system can interact with the IVR system 1630.Advantageously, in certain embodiments, configuring a computer system tointeract with the IVR system 1630 enables interacting with the IVRsystem 1630 using an automated system and/or process.

Example of an IVR Based Token Sharing Process

FIG. 17 illustrates a flow diagram for an example embodiment of aninteractive voice response (IVR) based token sharing process 1700. Theprocess 1700 can be implemented by any system that can interact with asystem or user via voice input and audio output to enable a user toshare a token with another user or entity. For example, the process1700, in whole or in part, can be implemented by one or more of thetoken access system 1622, the IVR system 1630, the token access system122, and the token access system 1322. Although any number of systems,in whole or in part, can implement the process 1700, to simplifydiscussion, portions of the process 1700 will be described with respectto particular systems.

The process begins at block 1702 where, for example, the token accesssystem 1622 authenticates a user via the IVR system 1630. Authenticatingthe user can include requesting the user provide information associatedwith the user to the IVR system 1630. This information can include aunique identifier (e.g., a social security number, a unique accountnumber, etc.), a pin number, an answer to a security question, a name,or any other information that can be used to help identify the user orverify the user's specified identity. If the user is not successfullyauthenticated, the process 1700 may end, provide the user an opportunityto re-authenticate, and/or alert an administrator. Generally, the useris a human. However, in some cases, the user may be an automated systemor a computing system.

At block 1704, the IVR system 1630 prompts the user to provide a token.The IVR system 1630 receives the token from the user at block 1706. Thistoken can include any string of alphanumeric characters and symbols thatmay be supplied via a phone and/or keyboard and can be associated withCHD. At decision block 1708, the token access system 1622 determineswhether the user is associated with the token. In some embodiments,determining whether the user is associated with the token can includedetermining whether the user is identified as an owner of the token.Further, in some cases, determining whether the user is associated withthe token can include determining whether the user is authorized toshare the token with other users.

If the user is associated with the token, the IVR system 1630 providesthe user with the authorization factor at block 1710. Providing theauthorization factor to the user enables the user to share token accesswith a another user, or third-party user, to whom the user provides theauthorization factor. In some embodiments, the third-party user may beprevented from accessing the token regardless of whether the third-partyuser has the authorization factor. For example, if the third-party useris not registered with the token access system 1622, having access tothe authorization factor may not be sufficient to use the token oraccess CHD associated with the token. In some embodiments, the block1710 can include the user identifying or registering the third-partyuser to whom the user intends to share the authorization factor therebyenabling the token access system 1622 to verify that a user providingthe authorization factor to the token access system 1622 is authorizedto access the token. Advantageously, in certain embodiments, registeringthe intended recipient or third-party user with the token access system1622 creates a multi-factor authorization system as the third-party usershould be registered with the token access system 1622 and should haveaccess to the authorization factor before accessing a token.

The authorization factor provided at the block 1710 can include any typeof authorization factor that may be provided by an IVR system 1630. Forexample, the authorization factor can include a set of words,characters, numbers, or sounds. Moreover, in some cases, theauthorization factor provided by the IVR system can include some or allof the embodiments previously described with respect to authorizationfactors. For example, the authorization factor may be associated with atheme, such as colors, animals, or places. In some cases, anauthorization factor may be easier to remember than a token. Thus, incertain cases, a user may use the process 1700 to obtain anauthorization factor for his or her own use to facilitate accessing atoken. Moreover, in certain cases, the authorization factor may be usedas the token.

If the user is not associated with the token, the token access system1622 rejects the user at block 1712. Rejecting the user can include theIVR system 1630 informing the user that the user is not authorized toaccess the token. In some embodiments, the block 1712 can include someor all of the embodiments described above with respect to the blocks 506and 1406.

Example of a Token Generation Process

FIG. 18 illustrates a flow diagram for an example embodiment of a tokengeneration process 1800. The process 1800 can be implemented by anysystem that can generate a token to be associated with CHD received viaan IVR system. For example, the process 1800, in whole or in part, canbe implemented by one or more of the token access system 1622, the IVRsystem 1630, the token access system 122, and the token access system1322. Although any number of systems, in whole or in part, can implementthe process 1800, to simplify discussion, portions of the process 1800will be described with respect to particular systems.

The process begins at block 1802 where, for example, the token accesssystem 1622 authenticates a user via the IVR system 1630. Authenticatingthe user can include requesting the user provide information associatedwith the user to the IVR system 1630. This information can include aunique identifier (e.g., a social security number, a unique accountnumber, etc.), a pin number, an answer to a security question, a name,or any other information that can be used to help identify the user orverify the user's specified identity. If the user is not successfullyauthenticated, the process 1800 may end, provide the user an opportunityto re-authenticate, and/or alert an administrator. Generally, the useris a human. However, in some cases, the user may be an automated systemor a computing system. In certain embodiments, the block 1802 isoptional.

At block 1804, the IVR system 1630 prompts the user to provide one ormore pieces of CHD. This CHD can generally include any type of CHD, suchas a card number, an expiration date, a card security or verificationcode (e.g., a CVC code, a CVV2 code, a CVC2 code, etc.), a cardholdername, etc. In some cases, the requested CHD may depend on the type ofcard and/or the entity associated with the token access system 1622 orusing the token access system 1622. The IVR system 1630 receives the CHDfrom the user at block 1806. Subsequent to receiving the CHD, the tokenaccess system 1622 verifies the CHD at block 1808. Verifying the CHD caninclude any process that may be used to verify at least a subset of theCHD. For example, verifying the CHD can include performing one or morealgorithmic checks on the CHD, (e.g., a Luhn test), contacting aprovider of the card associated with the CHD, and performing amicro-transaction or a small transaction using the CHD. In someembodiments, the block 1808 may be optional.

At block 1810, the token access system 1622 generates a token. In someembodiments, the block 1810 can include some or all of the embodimentsdescribed above with respect to the block 204. Further, the token caninclude any type of token as has previously been described. Typically,the token is unique. However, in some cases, a token may be a duplicatetoken or a reused token. For example, a token associated with expiredCHD may be re-associated with CHD that is not expired. Moreover,although the token generally includes a random or pseudo-random valuethat is unrelated to the CHD, in some cases, the token may be based, atleast in part, on the CHD. For example, the first portion of the tokenmay include a portion of CHD (e.g., the first 4-digits of a card number)or may be generated based on the portion of the CHD.

The token access system 1622 associates the token with the CHD in arepository at block 1812. This repository can include any repository ordata store designed to store a relationship between a token and CHD. Forexample, the repository can include the token/CHD relationshiprepository 132. In some cases, the block 1812 can include storing theCHD and the token in the repository. In certain embodiments, the block1812 can include one or more of the embodiments described above withrespect to the block 206.

At block 1814, the authorization factor generator 128 generates anauthorization factor associated with the token. The authorization factorcan include any type of authorization factor as previously describedwith respect to FIG. 1. Further, in some cases, the authorization factorcan include a set of random or pseudorandom words as described withrespect to the block 416. For example, the authorization factor may bethe following set of four words: green, dog, circle, grape. Generally,the authorization factor is unrelated to the token. However, in somecases, the authorization factor may be generated based, at least inpart, on the token. For example, the authorization factor generator 128may use portions of the token as an index for selecting words or valuesin a dictionary of available options. This dictionary may be predefinedor it may itself be generated as, for example, part of the block 1814.Advantageously, in certain embodiments, the authorization factor canserve as an “anglicized” token or a simplified token that is easier toremember than the token generated at the block 1810, which may include,for example, a string of random letters, numbers, and/or symbols.Moreover, in certain embodiments, the block 1814 can include some or allof the embodiments described with respect to the block 416.

The token access system 1622 associates the authorization factor withthe token in a repository at block 1816. This repository may be the samerepository, described with respect to the block 1812, that stores theassociation between the token and the CHD. Alternatively, theauthorization factor and token relationship may be stored at anotherrepository, such as the token access repository 134. In certainembodiments, the block 1816 can include some or all of the embodimentsdescribed with respect to the block 418. Further, in certainembodiments, the block 1816 can include associating the authorizationfactor with the user. In such embodiments, the block 1816 may includeone or more of the embodiments previously described with respect to theblock 420. Moreover, in certain embodiments, the block 1816 can includeassociating the authorization factor with one or more additional usersspecified by the user.

At block 1818, the IVR system 1630 provides the authorization factor tothe user. The authorization factor may be presented to the user viaaudio, images, video, or any combination thereof. Further, in somecases, the authorization factor may be provided to one or moreadditional users whom the user has specified as being authorized toaccess the token. In certain embodiments, the block 1818 can include oneor more of the embodiments described above with respect to the block422. Instead of, or in addition to, using the IVR system 1630 to preventthe authorization factor to the user the token access system 1622 mayprovide the authorization factor to the user via any other communicationmechanism for providing information to a user. For example, the tokenaccess system 1622 can provide the authorization factor to the user viaa text message, an email, a voicemail message, or an instant message, toname a few.

Third Example of a Token-Sharing Environment

FIG. 19 illustrates an example embodiment of a token-sharing environment1900. The token-sharing environment 1900 illustrates an exampleembodiment of multiple tokenization provider systems (e.g., thetokenization provider systems 1902, 1904, and 1906) sharing access to asingle token access system 1922, which enables merchants to share accessto tokens created by the tokenization provider systems. Although asingle token access system is illustrated, it is possible, in somecases, for the tokenization provider systems to have access to multipletoken access systems. Further, although the token access system 1922 isillustrated as a separate system from the tokenization provider systems,it is possible for at least some of the token access system 1922 to bepart of the tokenization provider systems.

In some embodiments, the token access system 1922 is operated by adifferent entity than each of the tokenization provider systems.Alternatively, the token access system 1922 may be part of one of thetokenization provider systems or operated by an entity that operates oneof the tokenization provider systems. The remaining tokenizationprovider systems may then rent or purchase the use of the token accesssystem from the tokenization provider system, or the entity thatoperates the tokenization provider system. For example, the token accesssystem 1922 may be part of the tokenization provider system 1902, andthe operators of tokenization provider systems 1904 and 1906 maycontract to use the token access system from the operator of thetokenization provider system 1902. Advantageously, in certainembodiments, the entities that operate the tokenization provider systems1904 and 1906 may provide the service of enabling their tokens to beshared without managing their own token access system by using the tokenaccess system associated with the tokenization provider system 1902.

The tokenization provider systems can communicate with the token accesssystem 1922 via the network 170. Further, the merchants 1910 and 1912can communicate with the token access system 1922 and the tokenizationprovider systems via the network 170. In some cases, at least one of themerchants can be a third-party merchant environment (e.g., the thirdparty merchant environment 106) as previously described. In some cases,the merchant 1910 may serve as a third-party merchant to the merchant1912 and vice versa.

In certain embodiments, the token access system 1922 can createauthorization factor pools (e.g., four word pools, image pools, soundpools) that are uniquely associated with one of the tokenizationprovider systems. Thus, each tokenization provider system can beassociated with a unique pool of authorization factors. For example,assuming that the authorization factor is based on sets of words, thetokenization provider system 1902 may be associated with a word poolthat includes words starting with letters ‘A’-‘H’, the tokenizationprovider system 1904 may be associated with a word pool that includeswords starting with letters ‘I’-‘N’, and the tokenization providersystem 1906 may be associated with a word pool that includes wordsstarting with letters ‘O’-‘Z’.

The token access system 1922 can include multiple authorization factorpool repositories that can be associated with the tokenization providersystems. Each of the tokenization factor pool repositories can includethe authorization factors that can be used or randomly selected forenabling a merchant, or third-party merchant, to obtain access to atoken from a particular tokenization provider system. For example, thetokenization provider system 1902 may be associated with theauthorization factor pool 1932, the tokenization provider system 1904may be associated with the authorization factor pool 1934, and thetokenization provider system 1906 may be associated with theauthorization factor pool 1936. In some embodiments, each of theauthorization factor pools may be stored in the same repository.Alternatively, each of the authorization factor pools may be stored inseparate repositories, which may or may not be stored at the samelocation. In some embodiments, each authorization factor pool mayinclude different authorization factor types and/or algorithms. Forexample, the authorization factor pool 1932 may include an algorithm forselecting random words, the authorization factor pool 1934 may includean algorithm for selecting random digits, and the authorization factorpool 1934 may include an algorithm for selecting a combination of imagesand pass-phrases.

Advantageously, in certain embodiments, by associating differentauthorization factor pools with each tokenization provider system,tokens may be further protected because the authorization factors wouldbe specific to the tokenization provider system associated with theauthorization factor pool. Thus, for example, an authorization factorgenerated based on one authorization factor pool would not be meaningfulor understood by tokenization provider systems not associated with theauthorization factor pool.

Each time a merchant, such as merchant 1910, requests an authorizationfactor to be provided to a third-party merchant, such as the merchant1912, to enable the third-party merchant to access a token, the tokenaccess system 1922 can determine which tokenization provider systemgenerated the token. The authorization factor generator 1928 can thengenerate an authorization factor, such as a set of words, using theauthorization factor pool associated with the tokenization providersystem that generated the token. For example, if the token access systemdetermines that the token identified by the merchant 1910 was generatedby the tokenization provider system 1904, the authorization factorgenerator 1928 can generate an authorization factor using authorizationfactor pool 1934.

In some embodiments, the authorization factor is associated with thetoken or a reference to the token at the token access repository 1940.Alternatively, or in addition, the authorization factor may beassociated with the token or the reference to the token at theauthorization factor pool corresponding to the tokenization providersystem that generated the token.

As previously described, in certain embodiments a third-party merchantprovides the authorization factor to the token access system 1922 toobtain access to the corresponding token associated with theauthorization factor. The token access system 1922 can determine thetokenization provider system communicate with to obtain access the tokencorresponding to the authorization factor based on the authorizationfactor. For example, if the authorization factor is a set of words, andeach of the words starts with a letter from ‘A’-‘H,’ the token accesssystem 1922 can determine that it should access the tokenizationprovider system 1902. In some embodiments, the merchant attempting toobtain access to the token can specify the tokenization provider systemwhen providing the authorization factor. The token access system 1922can then determine if the selected tokenization provider system is thetokenization provider system associated with the authorization factor.If so, the token access system 1922 can proceed with a process (e.g.,the process 500) for granting the merchant with access to the token, orassociated CHD. If the token access system determines that the user orthird-party merchant identified the wrong tokenization provider system,the token access system 1922 can prevent access to the requested tokenor CHD.

In some embodiments, after obtaining access to the token correspondingto an authorization factor, the token access system 1922 can provide thethird-party merchant with access to the corresponding CHD using the CHDaccess system 1924, which can include some or all of the embodimentspreviously described with respect to the CHD access system 124 and/or1324. Alternatively, or in addition, the tokenization provider systemthat generated the token provides access to the CHD associated with thetoken. As previously described, providing access to a token and/or CHDcan, in some cases, include providing a user or merchant with a copy ofthe token and/or CHD. In other cases, providing access to a token and/orCHD can involve enabling a user or merchant to use the token and/or CHDwithout enabling the user or merchant to view the token and/or CHD.

Third Example of a Token Provisioning Process

FIG. 20 illustrates a flow diagram for a third example embodiment of atoken provisioning process 2000. The process 2000 can be implemented byany system that can associate a token corresponding to CHD of acardholder with a merchant other than the merchant that caused the tokento be created. For example, the process 2000, in whole or in part, canbe implemented by one or more of a tokenization provider system (e.g.,the tokenization provider system 1922), a token access system 1922, anauthorization factor generator 1928, the token access system 122, theCHD access system 124, the gateway 126, etc. Although any number ofsystems, in whole or in part, can implement the process 2000, tosimplify discussion, the process 2000 will be described as beinggenerally implemented by specific systems. In some embodiments, theprocess 2000 can be used to provide either a merchant, or an employee ofthe merchant or the merchant environment with access to a token or CHDassociated with the token.

The process 2000 begins at block 2002, where, for example, the tokenaccess system 1922 receives the identity of a token from a merchant(e.g., the merchant 1910). In some embodiments, the block 2002 caninclude some or all of the embodiments as previously described forreceiving the identity of a token, such as the embodiments describedwith respect to the block 408. Further, in some embodiments, the process2000 may include identifying the merchant, or user, and determiningwhether the merchant is authorized to grant token access, as describedpreviously with respect to, for example, the process 400.

At bock 2004, the token access system 1922 identifies a tokenizationprovider system (e.g., the tokenization provider system 1922) thatgenerated the token identified at the block 2002. In some embodiments,the token access system 1922 may identify the tokenization providersystem based on the identified token, data received from the merchant,information stored in one or more repositories (e.g., the token accessrepository 1940), by querying one or more tokenization provider systemsor by any other method for identify a tokenization provider system thatgenerated a token.

At block 2006, the authorization factor generator 1928 generates anauthorization factor based on the authorization factor pool associatedwith the tokenization provider system identified at the block 2004. Forexample, assuming the tokenization provider system 1922 is associatedwith the authorization factor pool 1932, and that the token identifiedat the block 2002 was generated by the tokenization provider system1922, the authorization factor generator 1928 may generate theauthorization factor based on an algorithm or pool of eligibleauthorization factors stored at the authorization factor pool 1932.Generating the authorization factor can include selecting anauthorization factor, either randomly, pseudo-randomly, orprogrammatically based on an algorithm. These authorization factors caninclude any type of authorization factor as previously described withrespect to, for example, FIG. 1 and/or the block 416. For example, theauthorization factor can be a set of one or more random words, or a setof images.

At block 2008, the token access system 1922, or the authorization factorgenerator 1928, associates the authorization factor with the token. Insome embodiments, the association between the authorization factor andthe token may be stored at the token access repository 1940. In otherembodiments, the association may be stored at the authorization factorpool associated with the tokenization provider system that generated thetoken. Alternatively, or in addition, the association may be stored atthe tokenization provider system that generated the token. Further, insuch cases, the token access system 1922 may provide the authorizationfactor to the tokenization provider system, and the tokenizationprovider system may associate the authorization factor with the token.In some embodiments, the block 2008 may include some or all of theembodiments previously described with respect to, for example, the block418.

At block 2010, the token access system 1922 receives the identity of amerchant (e.g., the merchant 1912). Generally, although not necessarily,the merchant identified at the block 2010 differ from the merchant thatprovided the identity of the token at the block 2002. In someembodiments, the block 2010 may include some or all of the embodimentspreviously described with respect to, for example, the block 410.Further, as previously described with, for example, the process 400, theprocess 2000 may, in some embodiments, include determining whether themerchant identified at the block 2010 is authorized to access tokens.

The token access system 1922, at block 2012, associates theauthorization factor with the merchant identified at the block 2010. Insome embodiments, the tokenization provider system that generated thetoken may perform the block 2012 in response to receiving the identityof the merchant from the user and/or the token access system 1922. Insome embodiments, the block 2012 may include some or all of theembodiments previously described with respect to, for example, the block420.

At block 2014, the token access system 1922 provides the authorizationfactor to the merchant identified at the block 2010. In someembodiments, the token access system 1922 provides the authorizationfactor to the merchant that identified the token at the block 2002, whocan then provide the authorization factor to the merchant identified atthe block 2010. In some embodiments, the block 2014 may include some orall of the embodiments previously described with respect to, forexample, the block 422.

Fourth Example Process for Accessing Cardholder Data

FIG. 21 illustrates a flow diagram for a fourth example embodiment of aprocess 2100 for accessing cardholder data. The process 2100 can beimplemented by any system that can provide a merchant (e.g., themerchant 1912) with access to a token and, in some cases, CHD associatedwith the token, which was created in response to another merchant (e.g.,the merchant 1910) providing the CHD to a tokenization provider system(e.g., the tokenization provider system 1902). For example, the process2100, in whole or in part, can be implemented by one or more of thetoken access system 1922, the tokenization provider system 1902, tokenaccess system 122, the CHD access system 124, and the gateway 126.Although any number of systems, in whole or in part, can implement theprocess 2100, to simplify discussion, the process 2100 will be describedas being generally implemented by specific systems.

The process 2100 begins at block 2102 where, for example, the tokenaccess system 1922 receives an authorization factor from a user (e.g.,the merchant 1912, or a representative thereof). In some embodiments,the block 2102 may include some or all of the embodiments previouslydescribed with respect to, for example, the block 508. Further, in someembodiments, the process 2100 may include receiving authenticationinformation from the user and determining whether the user is authorizedto access the token access system 1922 or a tokenization provider systemassociated with the authorization factor and/or corresponding token, asdescribed previously with respect to, for example, the process 500.

At block 2104, the token access system 1922 identifies a tokenizationprovider system associated with the authorization factor. Identifyingthe tokenization provider system associated with the authorizationfactor can include accessing an authorization factor pool associatedwith the authorization factor. Determining the tokenization providersystem and/or authorization factor pool corresponding to theauthorization factor may be based on the authorization factor, theidentity of the user, and/or information received from the user. Forexample, if the authorization factor is a set of images, the tokenaccess system 1922 may determine that the relationship between theauthorization factor and the token is stored at the authorization factorpool 1934 and that the tokenization provider system 1904 generated thetoken.

At block 2106, the token access system 1922 identifies a tokenassociated with the authorization factor at the tokenization providersystem identified at the block 2104. In some embodiments, the block 2106may include some or all of the embodiments previously described withrespect to, for example, the block 510 and/or 514.

At block 2108, the token access system 1922 provides the user withaccess to the token associated with the authorization factor. In someembodiments, the block 2108 may include the CHD access system 1924providing the user with access to the CHD associated with the token. Insome cases, the user is provided with access to the token and/or CHDwithout enabling the user to view the token and/or CHD. Further, in somecases, the block 2108 can include causing the tokenization providersystem that generated the token to provide the user with access to thetoken and/or corresponding CHD. In some embodiments, the block 2108 mayinclude some or all of the embodiments previously described with respectto, for example, the block 514 and/or 516.

The token access system 1922 disassociates the authorization factor fromthe token and the user at block 2110. Disassociating the authorizationfactor from the token and the user can include disassociating theauthorization factor from the token and/or user at one or more of theauthorization factor pool repository and the tokenization providersystem corresponding to the token. In some embodiments, the block 2110may include some or all of the embodiments previously described withrespect to, for example, the block 518. In some embodiments, the block2110 is optional.

Example of a Token-Provisioning Process Using a Machine-Readable Code

FIG. 22 illustrates a flow diagram for an example embodiment of atoken-provisioning process 2200 using a machine-readable code. Theprocess 2200 can be implemented by any system that can provide amerchant (e.g., the third-party merchant 162 associated with thethird-party merchant environment 106) with access to a token and, insome cases, CHD associated with the token, which was created in responseto another merchant (e.g., the merchant 142) providing the CHD to atokenization provider system (e.g., the tokenization provider system102). For example, the process 2200, in whole or in part, can beimplemented by one or more of the tokenization provider system 102, thetoken access system 122, the CHD access system 124, the authorizationfactor generator 128, and the gateway 126, to name a few. Although anynumber of systems, in whole or in part, can implement the process 2200,to simplify discussion, the process 2200 will be described as beinggenerally implemented by specific systems.

The process 2200 begins at block 2202 where, for example, the tokenaccess system 122 accesses an authentication factor associated with atoken. Accessing the authentication factor can include generating theauthentication factor, such as was previously described with respect tothe block 416. Further, as has previously been described, theauthentication factor can include any type of authentication factorincluding a set of random or pseudo-random words. In some embodiments,accessing the authentication factor associated with the token caninclude performing one or more of the previously described embodimentsfor associating a token with a merchant or a third-party merchant whodid not initiate creation of the token, such as the embodimentsdescribed with respect to the process 400.

At block 2204, the token access system 122 accesses an identifierassociated with a merchant who is associated with the authenticationfactor. This merchant is typically a third-party merchant (e.g., thethird-party merchant 162) who has been granted access, at leasttemporarily, to a token created for another merchant (e.g., the merchant142). However, in some cases, the merchant may be the same merchant forwhom the token was created.

At block 2206, the token access system 122 generates a machine-readablecode that includes the authentication factor and the merchantidentifier. In some embodiments, the machine-readable code may includethe authentication factor without including the merchant identifier.Further, in some cases, the machine-readable code may include a URL orURI for accessing a network page or webpage associated with thetokenization provider system 102. This webpage may be configured forreceiving the authentication factor, for providing access to the token,and/or for providing access to CHD associated with the token. In somecases, the machine-readable code may include an expiration date (and/ortime) or a creation date (and/or time).

The machine-readable code can include any type of machine-readable code.In some embodiments, the machine-readable code may include any code thatis sufficiently dense so as to be capable of encoding the informationdescribed above with respect to the block 2206 within a particular sizecode. In some cases, the machine-readable code may be a linear code(e.g., U.P.C., MSI, Code 128, etc.) or a stacked linear code (e.g., astacked barcode). Alternatively, or in addition, the code may be amatrix, or 2D, type code. In certain embodiments, using a matrix typecode enables more information to be encoded in the machine-readablecode. Some examples of matrix type machine-readable codes that may beused herein include: Quick Response (QR) codes, Aztec Codes, ShotCodes,MaxiCodes, PDF417 codes, SmartCodes In some embodiments,machine-readable code may include a combination of machine-readablecodes.

At block 2208, the token access system 122 provides the machine-readablecode to the merchant identified at the block 2204 (e.g., the third-partymerchant 162). Providing the machine-readable code to the merchantincludes emailing the machine-readable code to the merchant, presentingthe machine-readable code via a webpage, presenting the machine-readablecode via an application, such as an application for a mobile device orfor a POS system.

Example Process for Accessing CHD Using a Machine-Readable Code

FIG. 23 illustrates a flow diagram for an example embodiment of aprocess 2300 for accessing CHD using a machine-readable code, such as acode received via the process 2200. The process 2300 can be implementedby any system that can access a machine-readable code and extract anauthentication factor stored in the machine-readable code. Further, theprocess 2300 may be performed by any system that can use theauthentication factor stored in the machine-readable code to obtainaccess to a token associated with the authentication factor. Forexample, the process 2300, in whole or in part, can be implemented byone or more of the POS 166, the computing system 164, a computing system1364, a token access client 1390, and the CHD access system 1324, toname a few. Although any number of systems, in whole or in part, canimplement the process 2300, to simplify discussion, the process 2300will be described as being generally implemented by specific systems.

The process 2300 begins at block 2302 where, for example, the POS 166accesses a machine-readable code associated with a token. The POS 166may include a scanner that can scan the machine-readable code. In somecases, the machine-readable code may be displayed on a screen of acomputing system, such as the computing system 164, enabling themachine-readable code to be scanned from the screen. In other cases, themachine-readable code may be scanned from a handheld device (e.g., asmartphone) of a merchant (e.g., the third-party merchant 162).

At block 2304, the POS 166 extracts an authentication factor from themachine-readable code. For instance, the POS 166 may extract a set ofwords encoded into the machine-readable code. In some cases, the POS166, or other system capable of scanning the machine-readable code, mayscan the machine-readable code and provide information extracted fromthe machine-readable code to another computing system (e.g., thecomputing system 164).

At block 2306, the POS 166, or the computing system 164, provides theauthentication factor to the tokenization provider system 102. In somecases, the block 2306 includes determining the tokenization providersystem that manages the token associated with the authentication factorand providing the authentication factor to the identified tokenizationprovider system. In some embodiments, providing the authenticationfactor to the tokenization provider system 102 includes extracting a URLor URI from the machine-readable code, opening a webpage associated withthe URL or URI, and automatically providing the authentication factorvia the webpage. In other cases, the computing system 164 may displaythe authentication factor to a user (e.g., the third-party merchant 162)thereby enabling the user to enter the authentication manually into thewebpage.

At block 2308, the computing system 164 authenticates the merchant user(e.g., the third-party merchant 162) to the tokenization provider system102. Authenticating the merchant user can include accessing a digitalcertificate from a secure area of the computing system 164 and providingthe digital certificate to the tokenization provider system 102.Alternatively, or in addition, authenticating the merchant user mayinclude presenting the merchant user with a challenge-responseauthentication page provided by the tokenization provider system 102 forauthentication the merchant user. In some embodiments, the block 2308may be optional.

At block 2310, the POS 166 receives from the tokenization providersystem 102 access to the CHD associated with the token that isassociated with the authentication factor provided at the block 2306. Insome cases, the receiving access to the CHD includes receiving a copy ofthe CHD to use for a transaction and/or for a limited period of time. Inother cases, receiving access to the CHD includes being able to use theCHD at the tokenization provider system 102 by, for example, providinginformation for performing a transaction to the tokenization providersystem 102, which can then complete the transaction using the CHD onbehalf of the merchant user.

Additional Embodiments

Some embodiments of the present disclosure relate to a system forsharing cardholder data (CHD). Further, in some embodiments, the systemincludes a token access client associated with a first merchant or afirst merchant environment. The token access client may be configured toprovide a request to obtain access to a token associated with CHD to atoken access system associated with a second merchant or a secondmerchant environment. The request can include an authorization factor.In response to providing the request, the token access client mayreceive access to the token from the token access system. Further, thetoken access system can initiate a transaction using the token, therebyenabling the first merchant to initiate the transaction withoutreceiving a copy of the CHD.

In some embodiments, receiving access to the token includes receiving acopy of the token. Further, the token access client may be configured toinitiate the transaction by providing transaction information to atokenization provider system. In some cases, providing the transactioninformation to the tokenization provider system enables the tokenizationprovider system to perform the transaction. In some embodiments, thetokenization provider system generated the token.

In some embodiments, receiving access to the token includes receivingauthorization to use the token without receiving a copy of the token.Further, the token access client may be configured to initiate thetransaction by providing transaction information to the token accesssystem. In some cases, providing the transaction information to thetoken access system enables the token access system to initiate thetransaction.

In some embodiments, the request to obtain access to the token caninclude the transaction information. Further, the token access clientmay initiate the transaction by providing the request to the tokenaccess system.

In some embodiments, the token access client may be configured toidentify or to select a token access system from a plurality of tokenaccess systems. In some cases, the token access client may identify orselect the token access system based, at least in part, on theauthorization factor. Alternatively, or in addition, the token accessclient may identify or select the token access system based, at least inpart, on a user configuration of the token access client. For example,the user may identify the token access system, or a merchant associatedwith the token access system, at or near a time of the request to obtaintoken access. As a second example, the user may configure the tokenaccess client to identify the token access system based on a set ofcodes, a type of transaction, or any other information that can beassociated with a particular token access system.

Although the authorization factor and the token are described above asincluding random or pseudo-random values, one or both of theauthorization factor and the token may include non-random values. Forexample, a formula or algorithm may be used to identify one or morewords from a dictionary to use as an authorization factor.

Further, as has been described above, obtaining access to a token insome cases can include obtaining a copy of the token. In other cases,obtaining access to the token may include obtaining authorization to usethe token, but may not include obtaining a copy of the token. Further,in some cases, obtaining access to the token may include obtainingpermission to use the token whether or not a copy of the token isobtained.

Although merchants have been described as employees of merchantenvironments (e.g., retail establishments or entities), in some cases,merchants may include the merchant environment. Further, in some cases,the merchant may be a single individual, an organization, or a pluralityof individuals. Moreover, the merchant may be associated with abrick-and-mortar store, a network-based (e.g., Internet-based) store, orany other provider of goods or services.

A number of the processes described above describe one or more systemsinteracting with a user. For example, the process 500 describesreceiving user authentication information associated with thethird-party merchant 162 at the block 502. However, in certainembodiments, some or all of the previously described processes can beperformed by one or more systems interacting with one or more additionalsystems. For instance, again using the block 502 as an example, the userauthentication information may be associated with the computing system164. Alternatively, or in addition, the user authentication informationmay be associated with the third-party merchant 162 and may be receivedfrom the computing system 164, either in response to a user command orthrough an automated process.

Terminology

A number of computing systems have been described throughout thisdisclosure. The descriptions of these systems are not intended to limitthe teachings or applicability of this disclosure. Further, theprocessing of the various components of the illustrated systems can bedistributed across multiple machines, networks, and other computingresources. For example, the token access system 122, the CHD accesssystem 124, and the authorization factor generator 128 can each beimplemented as separate servers or computing systems, or alternatively,as one server or computing system. In addition, two or more componentsof a system can be combined into fewer components. Further, variouscomponents of the illustrated systems can be implemented in one or morevirtual machines, rather than in dedicated computer hardware systems.Likewise, the data repositories shown can represent physical and/orlogical data storage, including, for example, storage area networks orother distributed storage systems. Moreover, in some embodiments theconnections between the components shown represent possible paths ofdata flow, rather than actual connections between hardware. While someexamples of possible connections are shown, any of the subset of thecomponents shown can communicate with any other subset of components invarious implementations.

Depending on the embodiment, certain acts, events, or functions of anyof the algorithms described herein can be performed in a differentsequence, can be added, merged, or left out all together (e.g., not alldescribed acts or events are necessary for the practice of thealgorithms). Moreover, in certain embodiments, acts or events can beperformed concurrently, e.g., through multi-threaded processing,interrupt processing, or multiple processors or processor cores or onother parallel architectures, rather than sequentially. Although certaincomputer-implemented tasks are described as being performed by aparticular entity, other embodiments are possible in which these tasksare performed by a different entity.

Each of the various illustrated systems may be implemented as acomputing system that is programmed or configured to perform the variousfunctions described herein. The computing system may include multipledistinct computers or computing devices (e.g., physical servers,workstations, storage arrays, etc.) that communicate and interoperateover a network to perform the described functions. Each such computingdevice typically includes a processor (or multiple processors) thatexecutes program instructions or modules stored in a memory or othernon-transitory computer-readable storage medium. The various functionsdisclosed herein may be embodied in such program instructions, althoughsome or all of the disclosed functions may alternatively be implementedin application-specific circuitry (e.g., ASICs or FPGAs) of the computersystem. Where the computing system includes multiple computing devices,these devices may, but need not, be co-located. The results of thedisclosed methods and tasks may be persistently stored by transformingphysical storage devices, such as solid state memory chips and/ormagnetic disks, into a different state. Each service described, such asthose shown in FIG. 3, may be implemented by one or more computingdevices, such as one or more physical servers programmed with associatedserver code.

Conditional language used herein, such as, among others, “can,” “might,”“may,” “e.g.,” and the like, unless specifically stated otherwise, orotherwise understood within the context as used, is generally intendedto convey that certain embodiments include, while other embodiments donot include, certain features, elements and/or states. Thus, suchconditional language is not generally intended to imply that features,elements and/or states are in any way required for one or moreembodiments or that one or more embodiments necessarily include logicfor deciding, with or without author input or prompting, whether thesefeatures, elements and/or states are included or are to be performed inany particular embodiment.

While the above detailed description has shown, described, and pointedout novel features as applied to various embodiments, it will beunderstood that various omissions, substitutions, and changes in theform and details of the devices or algorithms illustrated can be madewithout departing from the spirit of the disclosure. As will berecognized, the processes described herein can be embodied within a formthat does not provide all of the features and benefits set forth herein,as some features can be used or practiced separately from others. Thescope of protection is defined by the appended claims rather than by theforegoing description. All changes which come within the meaning andrange of equivalency of the claims are to be embraced within theirscope.

1-11. (canceled)
 12. A system for sharing access to cardholder data (CHD), the system comprising: a token access system of a first merchant environment, the token access system comprising computer hardware and configured to: receive cardholder data (CHD) of a cardholder; obtain a token corresponding to the CHD, the token configured as a substitute for the CHD; discard the CHD from the token access system; receive a request to perform a transaction at a second merchant environment associated with a third-party; and authorize the second merchant environment to access the token enabling the third-party to use the CHD to perform the transaction without the third-party having access to the CHD.
 13. The system of claim 12, wherein the token access system is further configured to obtain the token by at least: transmitting the CHD to a tokenization provider system configured to generate tokens corresponding to received instances of CHD; and receiving the token from the tokenization provider system.
 14. The system of claim 12, wherein the token is generated based on the CHD.
 15. The system of claim 12, wherein the token comprises unique data configured to represent the CHD.
 16. The system of claim 12, wherein the token is formatted to mimic CHD.
 17. The system of claim 12, wherein the token access system is further configured to authorize the second merchant environment to access the token by authorizing a user of the third-party to access the token at a tokenization provider system.
 18. The system of claim 17, wherein authorizing the user of the third-party to access the token comprises enabling the third-party to use the token without providing a copy of the token to the user.
 19. The system of claim 17, wherein receiving the request to perform the transaction comprises receiving transaction details for the transaction, and wherein the token access system is further configured to perform the transaction on behalf of the third-party using the transaction details and the token.
 20. The system of claim 12, wherein the token access system is further configured to: generate an authorization factor; associate the authorization factor with the third-party; and provide the authorization factor to the third-party.
 21. The system of claim 20, wherein the authorization factor comprises one or more words, numbers, symbols, images, or sounds.
 22. The system of claim 20, wherein the token access system is further configured to: receive the authorization factor from the third-party; determine that the third-party is authorized to access the token based at least in part on the authorization factor; and provide access to the token to the third-party.
 23. A method of sharing access to cardholder data (CHD), the method comprising: by a token access system comprising computer hardware of a first merchant, receiving cardholder data (CHD) of a cardholder; obtaining a token corresponding to the CHD, the token configured as a substitute for the CHD; removing the CHD from the token access system; receiving a request to perform a transaction at a second merchant; and authorizing the second merchant to access the token enabling the second merchant to use the CHD to perform the transaction without having access to the CHD.
 24. The method of claim 23, wherein obtaining the token comprises: transmitting the CHD to a tokenization provider system configured to generate tokens corresponding to received instances of CHD; and receiving the token from the tokenization provider system.
 25. The method of claim 23, wherein authorizing the second merchant comprises enabling the second merchant to use the token without providing a copy of the token to the second merchant.
 26. The method of claim 23, wherein the token comprises unique data configured to represent the CHD.
 27. The method of claim 23, wherein the token is formatted to be used in place of the CHD.
 28. The method of claim 23, wherein authorizing the second merchant to access the token comprises authorizing the second merchant to access the token at a tokenization provider system.
 29. The method of claim 23, further comprising: generating an authorization factor; associating the authorization factor with the second merchant and the token; and providing the authorization factor to the second merchant.
 30. The method of claim 29, further comprising: receiving the authorization factor from the second merchant; determining that the second merchant is authorized to access the token based at least in part on the authorization factor; and providing access to the token to the second merchant.
 31. The method of claim 23, wherein receiving the request to perform the transaction comprises receiving transaction details for the transaction, and wherein the method further comprises performing the transaction on behalf of the second merchant using the transaction details and the token. 